# Platform integrations

**Whisper sits beside the 5G core you already run and anchors exactly one thing: a routable, verifiable identity at the SBI / N32 / NEF IP boundary. That's the layer where an impersonated network function or a spoofed roaming peer looks identical to the real one today, because every certificate in the chain terminates in a private CA no outsider can check.**

Everything below is a **proposed** integration pattern (our design, not a vendor endorsement), and every one is written the same way: *Whisper complements the mechanism you have; it never replaces it.* We do not touch **5G-AKA** in the UICC/eSIM, we do not conceal the **SUPI** as a **SUCI**, and we do not inspect **SS7 / Diameter / GTP-C** signalling messages on the wire. The subscriber plane, the radio air interface, and your signalling firewall are each already someone's job. Whisper's job is the network identity of whatever is talking to your control plane: an **NF** on the SBI, a **SEPP** at the roaming border, an **Open Gateway** API caller, an **O-RAN** component, expressed as an IPv6 `/128` that DNSSEC, DANE and RDAP can prove and one call can revoke.

> **One spine under all four.** Each integration below reuses the same shipped primitive: a deterministic `/128` derived from an NF's *public* key plus the `nfInstanceId` it already carries (the UUID that 3GPP already binds into the certificate SAN), passed as `device_id` ([NF identity](/docs/nf-identity)), published with a DANE-EE `3 1 1` pin and an RDAP record, verifiable by anyone with no account. The integrations differ only in *where in your network* that identity is bound and checked.

## Anchor the boundary, not the subscriber plane

A 5G network carries several trust mechanisms, each correct for its own layer. The mistake is to imagine a new identity system has to displace one of them. It doesn't. Whisper is deliberately confined to the one place none of them cover: the moment a network endpoint claims to be a particular NF, SEPP, or sanctioned API consumer, and the receiver has only an OAuth2 bearer token or a certificate chained to a private operator CA to go on.

| Layer | Owner / mechanism | Whisper's role |
|---|---|---|
| Subscriber ↔ network auth | 5G-AKA symmetric keys in the UICC/eSIM; SUPI concealed as SUCI (ECIES) | **none**: the subscriber plane, never the NF plane |
| Radio air interface | gNB / NR-Uu: PDCP ciphering & integrity | **none**: below the IP layer entirely |
| Signalling-message inspection | SS7 / Diameter / GTP-C & SBI firewalls (an incumbent's job) | **none**: an additive feed, never the packet inspector |
| NF ↔ NF / roaming / NEF (IP) | operator-private CA + SBI mTLS + OAuth2; SEPP/N32; NEF northbound | **anchors here**: a publicly verifiable `/128` the endpoint *is*, provable without the operator's private CA |

Read the last row as the whole thesis. On the SBI, TS 33.501 makes mutual TLS mandatory and the **certificate** is the identity anchor. TS 33.310 §6.1.3c even binds the identity into the cert, mandating a `subjectAltName` URI-ID of `urn:uuid:<nfInstanceId>`. But that certificate is signed by the operator's *private* CA, enrolled over CMPv2, with no public root: nothing outside the operator can validate it. Identity today is a *claim* that only your own PKI can check. Whisper turns it into a *network fact*: the source address itself, forward-confirmed in DNS, pinned in DANE, registered in RDAP.

```
owned by 5G-AKA / the RAN / signalling firewalls : Whisper never here  │  the one layer Whisper anchors
                                                                       │
┌──────────────────────────────────────────────────────┐              │  ┌──────────────────────────────────────┐
│  Subscriber ↔ network auth  · 5G-AKA · SUCI        ✕  │              │  │  SBI / N32 / NEF : the IP boundary    │
│  Radio air interface        · gNB · NR-Uu · PDCP   ✕  │     the      │  │  operator CA · mTLS · OAuth2 · SEPP    │
│  Signalling-message insp.   · SS7/Diameter/GTP-C   ✕  │    fence      │  │            │ derive + publish         │
└──────────────────────────────────────────────────────┘              │  │  NF /128 · DNSSEC · DANE-EE 3 1 1      │
                                                                       │  │  bound to urn:uuid:nfInstanceId ✓ here │
                                                                       │  └──────────────────────────────────────┘
```

*The subscriber plane, the air interface and the signalling firewall stay theirs. Whisper never crosses the fence: it anchors one layer, the identity of the endpoint on the IP fabric, provable without anyone's private CA.*

> **Where DANE/DNSSEC earns its keep.** This is a *second, independent* DNS-anchored layer, strongest at the trust *boundaries*: NF discovery and DNS, the N32 roaming border, NEF exposure, and management, not deep inside a single SBI where mTLS and the NRF already bind tightly. It never replaces the mandatory 3GPP mTLS + OAuth2. See [NESAS · NIS2 · 5G Toolbox](/docs/telecom-compliance) for the honest control-by-control map.

## The 5G NRF: the keystone

Every NF (AMF, SMF, UPF, PCF, UDM, AUSF, NSSF…) is an HTTP/2 + JSON microservice on the SBI, and it registers an **NFProfile** with the **NRF** (TS 29.510). That profile already carries the fields a public identity needs: an `nfInstanceId` (a UUID, RFC 4122), an `nfType`, an `nfStatus`, and at least one of `fqdn` / `ipv4Addresses` / `ipv6Addresses`. A resolvable NF identity *already exists*. It is just trapped inside the operator's private NRF and private PKI, verifiable only after bilateral cross-certification.

The integration is a near-literal drop-in, with **no NRF API change**. Derive a `/128` from the NF's *existing* SBI key plus its `nfInstanceId` (passed as `device_id`), then publish that address as one more entry in the NFProfile's `ipv6Addresses` array, beside the operator's own. Because the address is DNSSEC-anchored with a DANE `TLSA` that pins the *same certificate* the NF already presents on the SBI (the one whose SAN is `urn:uuid:<nfInstanceId>`), a roaming partner, a regulator, or another operator can resolve the address, pull the pin, and confirm "this address *is* NF X" without ever touching the operator's private CA.

```json
// The Whisper /128, published as one more entry in the NFProfile.ipv6Addresses array.
// NRF unchanged; the address is now a globally verifiable name for the same NF.
{
  "nfInstanceId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "nfType":       "SMF",
  "nfStatus":     "REGISTERED",
  "fqdn":         "smf01.5gc.mnc015.mcc234.3gppnetwork.org",
  "ipv6Addresses": [
    "2001:db8:5gc::a3f6",
    "2a04:2a01:9c0::a3f6"          // ← the Whisper /128: DNSSEC + DANE, publicly verifiable
  ]
}
```

Point a resolver at it and the identity confirms itself straight from the internet's own records. No NRF query, no operator PKI:

```bash
# The address is the NF: forward-confirmed reverse DNS names it.
dig -x 2a04:2a01:9c0::a3f6 +short
nf-3fa85f64.sba.<tenant>.agents.whisper.online.

# Pin the SBA certificate the NF already presents: the leaf key, in DNSSEC-signed DNS.
dig +dnssec TLSA _443._tcp.nf-3fa85f64.sba.<tenant>.agents.whisper.online
;; flags: qr rd ra ad          ← ad = DNSSEC-authenticated
;; _443._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 b653a4ef...fcb82d1d
```

The shipped *spine* attaches right here. The SBA certificate (whose key is already the anchor 3GPP trusts) is the birth certificate the `/128` is derived from: submit the NF's *public* SPKI, pass the `nfInstanceId` as `device_id`, and the NRF and its consumers can authorize a forge-proof address instead of only a portable token. The private key never leaves the NF; the derivation is deterministic and tenant-bound, and the full mechanics live on [NF identity](/docs/nf-identity).

```cypher
# The spine: derive the NF's /128 from the SBI key it already holds + its nfInstanceId.
CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SPKI of the NF's SBI key>',
  device_id:           '3fa85f64-5717-4562-b3fc-2c963f66afa6'   // the nfInstanceId (urn:uuid in the cert SAN)
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error
```

Send it with stock tools. The control plane is one HTTP endpoint; the key travels only in the header:

```bash
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  --data @- <<'JSON'
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'<base64 SPKI>', device_id:'3fa85f64-5717-4562-b3fc-2c963f66afa6'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}
JSON
{ "op":"connect", "ok":true, "status":"created",
  "result":{ "address":"2a04:2a01:9c0::a3f6",
             "fqdn":"nf-3fa85f64.sba.<tenant>.agents.whisper.online",
             "wireguard":{ /* peer, keys, allowed-ips */ } } }
```

> **The least-contestable win: close the DNS-spoofing / rogue-NRF gap.** 3GPP mandates mTLS and OAuth2 on the SBI but says *nothing* about DNSSEC or DANE on the name layer that NF discovery rides. Spoof that DNS and you can redirect an NF to a **rogue NRF** or forge the **token-issuer URL**: fake token issuance, NF impersonation, N32-c spoofing. A DNSSEC-signed zone with a DANE pin makes the *name → address → expected-cert* binding cryptographic, which mTLS alone never covers. That is the strongest, spec-level claim on this page.

> **Complements the NRF + its operator PKI, does not replace it.** The NRF stays the authoritative registry and OAuth2 authorization server; the operator's `CA→CMPv2` chain stays the NF's factory anchor. Whisper adds a publicly verifiable, DNSSEC/DANE-anchored name *on top*: a DANE-pin of the certificate the NF already presents, and a routable `/128` for each NF, with a DNS-TTL off-switch (below) that per-operator CRL/OCSP does not give you across a boundary. See [DANE & TLSA](/docs/dane) for the byte-for-byte record.

## SEPP & N32: verifiable peer identity at the roaming border

The **SEPP** is the mandatory PLMN-border gateway: all inter-PLMN SBI traffic crosses **N32** between two SEPPs (TS 29.573). **N32-c** is the TLS handshake that negotiates policy; **N32-f** carries the roaming messages, protected either by direct TLS between peers or, when **IPX** providers mediate, by **PRINS** (application-layer JWE + JWS), a model in which the IPX hub is *semi-trusted* and may read and modify whitelisted JSON. The SEPP also performs topology hiding, rewriting the `interPlmnFqdn` / telescopic FQDN and stripping internal addresses.

The consequence is a chain of *transitive, opaque* trust: the originating NF deep in the peer network is not independently verifiable by the home operator. Your security is your weakest roaming partner, and you cannot see which partner that is. GSMA **FS.36** names the N32-c spoofing vector specifically. This is the highest-leverage boundary on the whole network, and it is exactly where a public anchor helps most.

The integration gives each NF and each SEPP a DANE-pinned `/128` so the *home* operator can cryptographically verify a peer against a **public** anchor, independent of the peer's private CA and of any IPX in between. Instead of "trust the SEPP's assertion," it becomes "verify the address and its DANE pin against the DNSSEC root." This hardens N32-c; it does not touch PRINS or the N32-f message protection, which stay exactly as GSMA specifies.

```
transitive trust: asserted through the SEPP and (with PRINS) through the IPX, not provable

 ┌───────────┐      ┌───────────┐      ┌───────────┐      ┌───────────┐
 │ HPMN SEPP │─ ─ ─▶│ IPX/PRINS │─ ─ ─▶│ VPMN SEPP │─ ─ ─▶│  peer NF  │
 │  (home)   │      │semi-trust.│      │ (visited) │      │ deep VPMN │
 └─────┬─────┘      └───────────┘      └───────────┘      └─────┬─────┘
       │ home verifies →                        ← peer's published /128
       │                ┌──────────────────────────────────┐   │
       └───────────────▶│ Public DNSSEC root + DANE-EE pin  │◀──┘
                        │       2a04:2a01:9c0::5e00          │
                        │  no IPX · no cross-certified CA    │
                        └──────────────────────────────────┘
```

*The transitive chain stays exactly as 3GPP and GSMA specify. Whisper adds one thing: the home operator verifies the peer's DANE-pinned `/128` directly against the public DNSSEC root, so a spoofed N32-c peer has no valid public identity to present, independent of the IPX and the peer's CA.*

```bash
# The home operator confirms a roaming peer's SEPP before it trusts the border: no shared CA.
whisper verify --trustless sepp.vpmn-mcc262mnc02.<tenant>.agents.whisper.online
dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin
CRYPTOGRAPHICALLY PROVEN, trust anchor: DNSSEC root (IANA) + DANE-EE

# Kill a compromised interconnect identity everywhere in one TTL, not one CRL per operator.
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:9c0::5e00'}})
```

**See who is probing the border, before the message lands.** Because every NF and SEPP identity resolves through Whisper's own authoritative DNS and RDAP, you can ask *who looked*. `op:'lookups'` returns who has been resolving or RDAP-querying an identity. It's a reconnaissance tripwire for an attacker enumerating your NFs across the interconnect, caught in recon rather than in the post-mortem:

```cypher
# who has been resolving / RDAP-querying this NF or SEPP identity, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:9c0::5e00', window:'24h'}})
```

> **Complements the SEPP, N32 and PRINS, does not replace them.** The SEPP stays the border gateway; N32-c/N32-f and PRINS stay the message-protection model; the IPX stays where it is. Whisper adds a public anchor so peer identity is *provable*, not merely asserted, hardening the N32-c spoofing vector GSMA FS.36 names, and giving you a cross-operator kill-switch faster than any per-operator CRL. Note the honest limit: this revokes the `/128` and its egress authorization, *not* the operator's TLS certificate. That stays the operator CA's job.

## CAMARA / GSMA Open Gateway: a public anchor for the API caller and target

**GSMA Open Gateway** exposes network capability as developer- and agent-facing APIs: SIM-swap, number-verify, device-location, quality-on-demand, standardised through **CAMARA** and fronted by the **NEF** northbound. It is the network's new front door, and it inherits the full web-API threat model: broken object-level authorization, shadow endpoints, mis-scoped tokens. An API caller is a bearer token from anywhere; an API target is a hostname a client takes on faith.

This is the two-tier Postel shape at its cleanest. With **no key**, any developer or agent can verify (trustlessly, from the DNSSEC root) that the Open Gateway endpoint they are about to call really is the sanctioned target, and an aggregator can confirm a caller's network identity before honoring a request. With a **key**, the caller or the exposed service is itself provisioned a `/128`, source-bound so the request arrives from an allowlisted address a replayed token cannot forge.

```bash
# Keyless: a developer or agent confirms the Open Gateway API target before calling it.
curl https://whisper.online/verify-identity/2a04:2a01:9c0::ca3a
{"is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { … }}

# Keyed: bind an API caller's egress to its /128 and default-deny the rest.
whisper policy set --agent 2a04:2a01:9c0::ca3a \
  --default deny --allow api.opengateway.<tenant>.agents.whisper.online
```

> **Complements CAMARA's OAuth/consent model, does not replace it.** Who may call what, and under whose consent, stays with CAMARA and the NEF. Whisper anchors the *transport identity* on both sides: a target a caller can verify, a caller a gateway can allowlist by address, so the grant is enforced against a network fact, not a portable secret. See [Egress governance](/docs/egress-governance) for the full policy surface.

## O-RAN: a public /128 for every disaggregated component

An O-RAN deployment splits the RAN across suppliers: O-RU, O-DU, O-CU, the near-RT and non-RT RIC, and third-party xApps/rApps, talking over E2 (SCTP/E2AP), A1 (REST), O1 (NETCONF/YANG), O2 (REST) and the Open Fronthaul. O-RAN **WG11** (Feb 2025) mandates mTLS 1.2+ everywhere off the fronthaul, OAuth2 as the common authorization, and automated certificate management over CMPv2. It also runs a **Zero-Trust Architecture** program whose *first pillar is Identity*, benchmarked to the CISA Zero-Trust Maturity Model.

Multi-vendor disaggregation multiplies the parties that must trust each other's certificates, and each still chains to a private, per-vendor or per-operator CA. A vendor-neutral, publicly verifiable `/128` per O-RAN component serves the WG11 ZTA **Identity** pillar directly, without every vendor cross-certifying into one root. It augments the mandated mTLS / CMPv2 / OAuth2 across O1, O2 and A1 with a DANE pin any party can check, and adds per-component egress governance, the least-privilege the ZTA also asks for.

```bash
# Pin an A1 (or O1/O2) endpoint's leaf key in DNSSEC-signed DNS: no shared CA across vendors.
dig +dnssec TLSA _443._tcp.near-rt-ric.oran.<tenant>.agents.whisper.online
;; _443._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 9c0de5e0...a11f0d0d

# Least-privilege per component: default-deny what an O-DU may reach, in one call.
CALL whisper.agents({op:'firewall', args:{
  agent:   '2a04:2a01:9c0::0d0',                // the O-DU's /128
  default: 'deny',
  allow:   ['near-rt-ric.oran.<tenant>.agents.whisper.online',
            'smo.oran.<tenant>.agents.whisper.online']
}})
```

And because each component has a forge-proof address, its telemetry and its E2/A1 policy actions can be [signed under](/docs/sign-outputs) that `/128`, so the SMO, an operator SOC, and a vendor PSIRT can trust a measurement or a policy decision came from the real component, non-repudiably, rather than a spoofed peer in a multi-vendor mesh.

> **Complements O-RAN WG11 mTLS / CMPv2 / OAuth2, does not replace them.** The RIC and SMO stay the control plane; CMPv2 stays the certificate lifecycle. Whisper adds the vendor-neutral public anchor and per-component least-privilege that the ZTA Identity pillar calls for: a DANE-pinned `/128` every party can verify without a cross-certification exchange. See [Connect & egress](/docs/connect) for the transport tiers.

## The SIEM feed: Splunk, Sentinel & OpenCTI today

Identity and attribution are only useful to a telecom SOC if they land in the tools it already runs. Whisper emits every finding as a *signed* JSON evidence chain: a `whisper.identify` attribution result, an `op:'lookups'` enumeration alert, an identity mint or revoke from the transparency log, so it is machine-readable enrichment for your signalling firewall and threat-intel, not another console an analyst babysits. For NIS2 Art.23 incident reporting (24h / 72h / 1 month), that cryptographic attribution accelerates the who / where forensics.

**The Splunk connector is shipped today.** It maps each signed finding onto CEF and ECS fields and forwards it into Splunk, so a fleet-enumeration tripwire or a rotating-egress attribution becomes a correlatable event beside your Enea / P1 / Positive Technologies signalling telemetry:

```bash
# The signed finding the Splunk connector maps to CEF / ECS and forwards.
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(\"185.12.x.x\")"}' | jq '.result.evidence'
# -> a replayable, signed evidence chain -> CEF: deviceVendor=Whisper cs1=operator …
#    (the connector emits one event per finding; the chain re-verifies offline)
```

> **Nothing issued in the dark.** Every identity mint and every revoke is written to a public, append-only [Merkle transparency log](/docs/transparency) (RFC 6962 `tlog-tiles`, Ed25519-signed, anchored to Bitcoin via OpenTimestamps): an auditable, non-repudiable issuance-and-revocation trail your SOC and a regulator can replay. *Honest status:* the log is tamper-evident, signed and Bitcoin-anchored today, but it is **not yet independently witnessed**. Our two authoritative nodes co-signing is availability, not independence. It already speaks the C2SP `tlog-witness` protocol, so any external witness can co-sign; that step is on the roadmap and we label it as such rather than overclaim.

The **Microsoft Sentinel** connector and **OpenCTI** threat-intelligence integration ship today, mapped onto Sentinel's connector framework and OpenCTI's knowledge graph for continuous-monitoring workflows. **STIX 2.1 over TAXII** export is on the roadmap, not shipped. It is listed honestly under [On the roadmap](#roadmap) below.

## Shipped today vs proposed

Honesty about what runs matters more here than anywhere. The *identity primitive* under every integration is live and provable right now; the *integration guides* themselves are proposed patterns for wiring that primitive into each part of the network.

| Building block | Status |
|---|---|
| Deterministic `/128` from an NF's public key + `nfInstanceId` (as `device_id`) | **shipped, live** |
| Provision via the control plane (`op:'connect'`, WireGuard tier) | **shipped, live** |
| Keyless verify: `whisper verify --trustless`, `/verify-identity`, `dig -x`, RDAP | **shipped, live** |
| DANE-pin an existing endpoint's certificate (NRF / SBA / SEPP / O-RAN) over DNSSEC | **shipped, live** |
| Revoke: `/128` + PTR + DANE torn down at DNS-TTL speed | **shipped, live** |
| Egress governance: `op:'lookups'`, `op:'firewall'`, `op:'budget'`, policy | **shipped, live** |
| Attribution graph over the public API (`CALL whisper.identify(…)`) | **shipped, live** |
| **Splunk** connector: signed findings mapped to CEF / ECS | **shipped, live** |
| The four integration *guides* on this page (NRF, SEPP/N32, CAMARA, O-RAN) | **proposed**: our design, not a vendor endorsement |

> A dedicated `--nf-instance-id` CLI flag is **on the roadmap, not shipped**: NF provisioning today goes through the control-plane call shown in the keystone section above, which *is* live, with the `nfInstanceId` passed as the generic `device_id`. The CLI verbs that exist are `whisper verify --trustless`, `whisper create --register`, `whisper kill --revoke`, `whisper policy` and `whisper logs`.

## On the roadmap

These feed 5G-security evidence into the tools a telecom SOC and an NF-vendor PSIRT already run. They are **roadmap, not yet shipped**, listed here so you can see where this goes:

- **Microsoft Sentinel connector**: *shipped today*, alongside the **Splunk** connector.
- **OpenCTI** threat-intelligence integration: *shipped today*.
- **STIX 2.1 over TAXII export**: *roadmap*. Maps identity and egress evidence onto standard TI transports for NIS2 and continuous-monitoring workflows.
- **First-class typed `--nf-instance-id` argument**: *roadmap*. Today the generic `device_id` already accepts an `nfInstanceId`, or any NFProfile identity.
- **Independent witnessing of the transparency log**: *roadmap*. Tamper-evident and Bitcoin-anchored today; external co-signing via C2SP `tlog-witness` is the next step.

## Next

- [NF identity](/docs/nf-identity): the shipped derivation these integrations all build on
- [NF-impersonation cure](/docs/nf-impersonation-cure): the primary wedge, verifiable identity at the SBI and the roaming border
- [NESAS · NIS2 · 5G Toolbox](/docs/telecom-compliance): where the evidence lands, mapped honestly control by control

---

← [NF-impersonation cure](/docs/nf-impersonation-cure) · [NESAS · NIS2 · 5G Toolbox →](/docs/telecom-compliance)
