# Agriculture recipes

**Three copy-paste recipes put a forge-proof, owner-revocable network identity under a drone ground station, a prescription pipeline, and a genuine part. Each one runs today against the keyless verify surface anyone can reach.**

They share one primitive: a routable IPv6 `/128` that a device *derives* from a key it already holds, DNSSEC-signed and [DANE-pinned](/docs/dane) so anyone can verify it and nobody can forge it. Everything below is built from shipped parts: the device `/128`, keyless `verify`, and one-call `revoke`.

> **What's shipped, stated honestly.** The machine/ECU `/128` derivation, the keyless [verify](/docs/verify) / RDAP surface, and one-call [revoke](/docs/control-plane) are **live**. Two caveats: there is no `--pin` CLI flag yet, so machine provisioning is shown via the control-plane API with the PIN riding in the `vin` argument (which *is* live); and the SIEM/threat-intel *export* roadmap items at the end are proposed, not shipped. Whisper anchors the **cloud/IP boundary**: not the ISOBUS/J1939 bus, not TIM functional safety, not a drone's Remote-ID broadcast. Each recipe names exactly where it stops.

## The shared primitive: an identity a device derives, not one you hand it

A machine, an implement ECU, or a smart component already carries a hardware key from the factory: a secure-element or TPM key. Whisper takes only its **public** SPKI and, together with the 17-character equipment PIN (and optionally an implement or part serial), *deterministically derives* a `/128` under `2a04:2a01::/32` (`AS219419`). The private key never leaves the device.

- **Deterministic & idempotent:** the same key + PIN always yields the same `/128`.
- **Tenant-bound & fleet-unlinkable:** an outsider deriving under a different tenant gets a *different* address; no enumeration oracle.
- **Forge-proof:** DANE-EE `3 1 1`-pinned to that device's key, with DNSSEC-signed reverse DNS.
- **Revocable worldwide, by the owner:** one call tears everything down at DNS-TTL speed, publicly checkable in DNS.

```sh
# Provision a machine's identity from the device key it already holds + its PIN.
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'connect'"'"', args:{tier:'"'"'wireguard'"'"', identity_public_key:'"'"'<base64 SPKI of the device key>'"'"', vin:'"'"'1AGCM82633A004352'"'"'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}' | jq .

# For a specific implement or part, add ecu_serial for a distinct /128:
#   args:{tier:'wireguard', identity_public_key:'…', vin:'1AGCM82633A004352', ecu_serial:'RC-7F31'}
```

> The same device key with a *different* PIN on your tenant is a `409`, and a non-string identifier is a clear `400`. The server only ever derives a public **address**; it never sees the device's private key.

Once provisioned, every check in the three recipes below is **keyless**.

## Recipe 1: Drone ground-station & fleet-backend verification

An agricultural drone broadcasts its identity on the air under FAA Remote ID (Part 89); the internet side, the ground control station, the fleet backend, the spray-log upload, the USS/UTM endpoints, has no such identity. Give each one a `/128` and either side confirms the other with a stock DNS lookup.

> **Boundary.** Whisper is **not** in the Part-89 broadcast and issues **no** Remote-ID credentials. It authenticates the *IP-facing* peers the broadcast was never designed to cover.

```sh
# The client side: prove the fleet backend is who it claims, trustless
whisper verify --trustless fleet-backend.demo.agents.whisper.online
# dnssec pass · dane pass · ledger pass · CRYPTOGRAPHICALLY PROVEN

# The server side: is this address a real, DANE-anchored ground-station identity?
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
# {"is_whisper_agent":true,"dane_ok":true,"jws_ok":true, …}

# Forward-confirmed reverse DNS, with nothing but dig:
dig +short -x 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
# a6f1007b9e2d30c8.demo.agents.whisper.online.
```

Mutual, forge-proof peer verification at the layer Remote ID leaves open, and the spray log the traceability chain will later cite arrives from an identity anyone can re-check.

## Recipe 2: Bidirectional prescription & task-file verification

A prescription map is two trust questions: *is this really the FMIS endpoint the machine should fetch its task file from*, and *is this really the machine that's allowed to receive, and later report against, that prescription*.

> **Boundary.** The task file's content and format stay with your FMIS and the ISOBUS task-controller workflow: Whisper does **not** parse, sign or alter prescriptions. It authenticates the two *endpoints*.

**Direction A: the machine verifies the FMIS endpoint.**

```sh
whisper verify --trustless taskfiles.demo.agents.whisper.online
# dane pass: served leaf SPKI-SHA256 == TLSA pin

# Same check with stock tools:
dig +short TLSA _443._tcp.taskfiles.demo.agents.whisper.online
# 3 1 1 b653a4ef…fcb82d1d
openssl s_client -connect taskfiles.demo.agents.whisper.online:443 </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der \
  | openssl dgst -sha256        # must equal the TLSA pin above
```

**Direction B: the FMIS verifies the machine.**

```sh
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
# {"is_whisper_agent":true,"dane_ok":true,"jws_ok":true, …}
```

Two keyless checks, one in each direction, and the prescription only moves when both pass. A harvested platform token buys an attacker nothing.

## Recipe 3: The anti-counterfeit part

A genuine component holds a secure-element key from the factory; a counterfeit doesn't hold the one that was *registered*. Bind the genuine key to a Whisper `/128` at manufacture and the difference collapses into a one-line network check.

> **Boundary.** This complements the secure element already in the part. It does **not** replace the chip.

```sh
# Genuine part: a registered, DANE-anchored identity. It proves itself:
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
# {"is_whisper_agent":true,"dane_ok":true,"jws_ok":true, …}

# Counterfeit: no registered /128 for its key, no DANE pin it can present.
curl -s https://whisper.online/verify-identity/2a04:2a01::1
# {"is_whisper_agent":false, "detail":"no Whisper agent identity anchors this address"}

# The RDAP assignment record, keyless:
curl -s https://whisper.online/ip/2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
```

## One `revoke`, blacklisted worldwide, thrown by the owner

When a part is flagged counterfeit, a key is burned, or a machine is traded in, stolen, or decommissioned, one call tears down its `/128`, its PTR, and its DANE pin everywhere at once, bounded only by DNS TTL. And unlike the covert kill-switches agriculture has already seen exercised, this one leaves a public trail: anyone can check, with `dig`, that the identity is gone and when it went.

```sh
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:'"'"'revoke'"'"', args:{agent:'"'"'2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8'"'"'}})"}'

# With the CLI, the same teardown is one verb:
whisper kill --revoke 2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8
```

Revocation and counterfeit-detection are, deliberately, the *same* mechanism. On a legitimate resale, revoke and re-register under the new owner: the data trail moves with the title.

## Attribution: which fleet, which destinations (keyed)

```sh
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.identify(\"2a04:2a01:e5a7:41c9:a6f1:7b:9e2d:30c8\")"}' | jq .
```

This is the graph API, not a CLI subcommand. It feeds an equipment-security SOC: which destinations a fleet's telematics units resolve, task-file-CDN reputation, a gateway beaconing somewhere it shouldn't.

## Where each recipe stops (and what's roadmap)

| Recipe | Complements | Does *not* touch / replace |
|---|---|---|
| Drone ground & backend | FAA Remote ID (Part 89) on the air interface | the Part-89 broadcast; no Remote-ID credentials issued |
| Prescription & task files | the FMIS's own auth, the ISOBUS task-controller workflow | task-file content, format and signing |
| Anti-counterfeit part | the secure element in the part | the chip itself, the ISOBUS/J1939 bus, and TIM functional safety |

> **Roadmap, clearly labelled.** Streaming this evidence into a SIEM ships today for **Splunk**, **Microsoft Sentinel** and **OpenCTI**. A **STIX/TAXII** feed and sector-ISAC sharing formats for food & agriculture are proposed, not yet available. The `--pin` CLI flag is roadmap: provision machines via the control-plane API shown above, which is live. Nothing on this list is required for the three recipes; they run on shipped primitives alone.

## Next

- [Equipment & ECU identity](/docs/equipment-identity): the full derivation the `/128` above comes from, key + PIN to address
- [DANE & TLSA](/docs/dane): the `3 1 1` pin every check here rests on, byte for byte
- [Verify an agent](/docs/verify): the full keyless proof chain `whisper verify --trustless` walks
- [Agriculture compliance](/docs/agriculture-compliance): where these recipes map into ISO 24882, Data Act and ADT evidence

---

← [Agriculture compliance](/docs/agriculture-compliance) · [Equipment & ECU identity →](/docs/equipment-identity)