Machine-to-Machine Security

Per-device cryptographic identity for IoT fleets. No shared secrets, no key rotation, no propagation delays. Every device is its own trust boundary.

The Problem

Most IoT deployments share a single API key or HMAC secret across every device in the fleet. This creates a catastrophic single point of failure: compromise one device, and the entire fleet is exposed.

• Shared API keys across the fleet: Every device holds the same secret. Extracting it from one device gives access to all of them.
• Symmetric HMAC forgery: Any device that knows the shared HMAC key can forge messages as any other device. There is no sender authentication.
• No replay protection: Without nonces or timestamp windows, captured messages can be resubmitted indefinitely. The server cannot distinguish original from replayed.
• Revocation requires fleet-wide re-keying: When a device is compromised, new secrets must be pushed to every remaining device. This takes hours and creates a window of exposure.
• One device compromised = all devices compromised: The blast radius of a single breach is the entire fleet. Lateral movement is instant and unlimited.

Architecture

Per-Device Identity

import { Agent } from '@private.me/agent-sdk';

// Commissioning: one keypair per device
const device = await Agent.create();

device.did  // did:key:z6MkhaXg...
// Unique to this device. Cannot be forged.
// No shared secrets. No API keys.

Signed Envelopes

// Every message is signed by the device's Ed25519 key
const envelope = await device.send({
  to: serverDid,
  payload: {
    type: 'telemetry',
    unit: 'DEVICE-104',
    event: 'door.unlocked',
    timestamp: Date.now()
  }
});
// envelope.signature = Ed25519(device.privateKey, payload)
// Server verifies: Ed25519.verify(envelope.signature, device.did)

Replay Protection

import { RedisNonceStore } from '@private.me/agent-sdk';

const store = new RedisNonceStore(redisClient, {
  ttl: 60  // seconds
});

// Server-side: verify nonce is unique
const valid = await store.check(envelope.nonce);
// true  = first time seen, proceed
// false = replay attempt, reject

Trust Registry & Revocation

When a device is compromised, remove its DID from the trust registry. The effect is immediate — the very next message from that DID is rejected. No new secrets need to be pushed to any other device. No certificate revocation lists. No OCSP stapling. No propagation delay.

The trust registry supports three backends: MemoryTrustRegistry for development, HttpTrustRegistry for distributed deployments, and DidWebTrustRegistry for standards-compliant resolution. All three implement the same interface. All three enforce the same rule: if the DID is not in the registry, the message is rejected. Fail-secure by default.

Scope Graph

Each DID maps to a specific set of allowed operations. A sensor on Floor 3 has the scope floor3.sensor.* — it can report events for that zone and nothing else. A compromised sensor cannot read data from Floor 4, cannot send commands to the HVAC system, cannot access the building management network.

The blast radius of a compromised device is exactly one device's scope. Not the fleet. Not the building. One unit, with a maximum exposure window of 30 seconds before the nonce TTL expires.

Non-Repudiable Audit

Every message is Ed25519-signed. The audit log stores the envelope including the signature, the sender DID, and the payload hash. Even if the database is tampered with after the fact, the signatures remain independently verifiable against the device's public key.

This is non-repudiable: the device cannot deny sending the message, and no other entity could have produced a valid signature for that DID. For regulatory compliance (SOC 2, ISO 27001, NIST 800-53), the audit trail provides cryptographic proof of exactly which device performed which action, at what time, with what payload.

With shared HMAC keys, any device in the fleet could have generated the tag. The audit trail is meaningless — you know a valid key holder sent the message, but not which one. Ed25519 eliminates this ambiguity entirely.

Before vs After

Constrained Devices

import { Agent, GatewayTransport } from '@private.me/agent-sdk';

// Gateway runs the SDK on behalf of constrained devices
const gateway = await Agent.create({
  name: 'sensor-gateway',
  registry, transport,
});

// Device sends raw data to gateway via HTTP/MQTT
app.post('/ingest', async (req, res) => {
  const payload = req.body;
  await gateway.send({
    to: backendDid,
    payload,
    scope: 'telemetry:write',
  });
  res.json({ ok: true });
});