Security Model
Authentication, trust, and encryption
Security Model
How OctoMY™ ensures secure communication and controlled access between nodes.
Security Consideration
OctoMY™ follows a "human authority" principle - no automated system, including LLMs, can grant itself elevated trust. The operator (human user) must approve all trust relationships. This is a fundamental design decision that cannot be bypassed.
Design principles
Security in OctoMY™ follows these principles:
- Security by default - All communication is encrypted
- Human authority - Operators approve all trust decisions
- Minimal exposure - Nodes expose only what's necessary
- Graceful failure - Security failures lead to safe states
Ground rules
The security model has some intrinsic complexities. Trusting a random node is difficult - how can you be sure they are who they claim? With advanced communication patterns, there are many cases and edge cases to address. These ground rules establish the foundation:
Rule 1: Local authority
Each node has full authority over itself:
| Aspect | Description |
|---|---|
| Physical access | If you can access the physical UI of a node, you can take full control and shut out any other node from ownership |
| Local-only mode | Each node has a "local only" mode that shuts down all communication and execution of plans from external sources, allowing safe configuration changes during security escalations |
Rule 2: Three trust levels
| Level | Name | Description |
|---|---|---|
| 0 | No Trust | Default state - no access permitted |
| 1 | General Trust | Nodes can collaborate and control each other to a certain extent. No access to security settings such as which other nodes to trust |
| 2 | Skeptron | The skeptron-marked node becomes the full master and is allowed to make any change, including security settings |
Rule 3: Granular authorization
- In General Trust, it is possible to specify more granularity. Each node sets rules for what other nodes can do (e.g., "can move", "can use camera")
- In Skeptron mode, all granular rules are ignored - full access is granted
Rule 4: Group membership
A node can accept membership into one or more groups. Membership has two attributes:
| Attribute | Description |
|---|---|
| Control we have over the group | What actions we can take on group members |
| Control the group has over us | What actions group members can take on us |
A typical setup: one node has skeptron over a group, with zero or more nodes having skeptron or general trust to the group. This makes relationship management easy - to gain control over a new node, simply add it to the group.
Rule 5: Plan permissions
Plans interact with the permission system:
| Aspect | Behavior |
|---|---|
| Configuration changes | A plan can dictate configuration changes, including permission changes |
| Remote execution | A plan can be executed on a node from another. It will perform all permissible steps. If that node has skeptron authority, the plan executes completely |
| UI warnings | The UI should warn if there are missing permissions before execution |
| Self-correcting | If permissions change during execution, the plan should have self-correcting provisions |
| Persistent authority | If node A has skeptron over node B and starts executing a plan requiring skeptron permissions, execution continues with those permissions even when A and B lose communication |
Rule 6: Permission delegation
| Action | Behavior |
|---|---|
| Cross-delegation | A node with skeptron over two nodes A and B can delegate permissions it has over one to the other. For example, it can give A skeptron access to B |
| Giving up permissions | A node can give up its permission (but cannot regain them alone) |
| Plan-based permission changes | A node can give up trust as part of a plan's execution. For example, if node A has skeptron authority over node B, a plan on node B can remove this skeptron (given the plan executor has access) |
Cryptographic identity
Every node has a unique cryptographic identity:
Key generation
At first launch, each node generates:
- RSA key pair - For signing and encryption
- Unique ID - Derived from the public key hash
- Personality - Deterministically generated from the key (name, colors, voice)
Identity properties
- Persistent - Identity survives application restarts
- Portable - Can be backed up and restored
- Verifiable - Other nodes can verify identity cryptographically
- Human-readable - Identicon provides visual verification
Trust levels
OctoMY™ uses a graduated trust model with six levels:
| Level | Name | Description |
|---|---|---|
| 0 | Block | No communication allowed |
| 1 | Ignore | Messages silently discarded |
| 2 | Meet | Basic discovery allowed |
| 3 | Handshake | Session establishment allowed |
| 4 | Trust | Normal operation permitted |
| 5 | Depend | Full operational trust |
Trust progression
Trust properties
- Asymmetric - A can trust B without B trusting A
- Per-node - Trust is specific to each remote node
- Revocable - Trust can be withdrawn at any time
- Auditable - Trust changes are logged
Discovery and pairing
Discovery and pairing are separate processes:
Discovery
The automatic process of finding nodes and establishing identity:
-
Physical proximity established via:
- NFC (strongest guarantee)
- QR code scanning
- Bluetooth range
- Zoo GPS coordination
- LAN broadcast
-
Keys exchanged - Public keys shared
-
Challenge/response - Identity verified cryptographically
-
Identicons displayed - Visual confirmation for user
Pairing
The manual process of granting trust:
- User views discovered nodes
- User verifies identicons match expectations
- User assigns trust level
- Trust relationship recorded
Session security
Secure sessions are established via a 3-way handshake:
Session properties
- Mutual authentication - Both sides verify identity
- Forward secrecy - Session keys derived per-session
- Replay protection - Nonces prevent replay attacks
- Timeout handling - Stale sessions automatically closed
Packet security
Every packet in an established session has:
Integrity
- Cryptographic signature using sender's private key
- Recipient verifies with sender's public key
Confidentiality
- Payload encrypted with session-derived key
- Only session participants can decrypt
Authenticity
- Session ID binds packet to established session
- Sequence numbers prevent reordering
Tamper detection
The tamper protocol adds validation beyond basic packet integrity:
- Structural checks - Packet format validation
- Semantic checks - Content plausibility
- Timing checks - Suspicious timing patterns
- Rate limiting - Flood protection
Detected tampering:
- Logs the incident
- May trigger UI warning
- Plans can define automatic responses
Attack mitigation
Man-in-the-middle
- Prevented by public key cryptography
- Identicon verification catches substitution
Replay attacks
- Session nonces prevent replay
- Sequence numbers detect duplicates
Denial of service
- Rate limiting on incoming connections
- Honeymoon mode expires
- Exponential backoff for failed attempts
Key compromise
- Trust can be revoked immediately
- New identity can be generated
- Operator notification of anomalies
Operator authority
The operator (human user) has ultimate authority:
- Approves all trust relationships
- Can revoke trust at any time
- Receives security alerts
- Configures security policies
No node can grant itself elevated trust. LLMs cannot bypass operator approval.