Part 13 — SecurityLink to the section Part 13 — Security#

Maturity: Draft · Profiles: all

13.1 Threat model (summary)Link to the section 13.1 Threat model (summary)#

Assets: live video, position history (sensitive: reveals operations and patrol patterns), control authority over an aircraft (safety-critical), device identity (impersonation enables injection of false video or telemetry), audit integrity.

Adversaries: network attacker on the path (internet or site LAN), compromised VMS operator account, compromised gateway host, malicious or buggy third-party client, rogue device presenting itself as a legitimate drone.

Design responses: no plaintext anywhere; strong mutual identity; least-privilege scopes separating view, camera and aircraft; short-lived leases; mandatory audit; schema validation of all inputs.

13.2 Transport securityLink to the section 13.2 Transport security#

• TLS 1.3 (RFC 8446) is REQUIRED on every UNIVIP connection (REST, WebSocket, MQTT, RTSP). TLS 1.2 MUST NOT be negotiated. Cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256.
• Connections to an OAuth 2.0 token endpoint (§13.3) are not UNIVIP connections: they follow the identity provider's policy and MUST use TLS 1.2 or later. A device presents its client certificate there only when the provider requires mTLS client authentication (RFC 8705).
• WebRTC media uses DTLS-SRTP as defined by WebRTC; SRT uses AES-128/256; both are REQUIRED when those transports are used.
• Certificates: devices MUST validate server certificates against a configured trust anchor (public CA or operator CA). Certificate pinning is RECOMMENDED for the configured endpoint. Plain rtsp:// and http:// MUST NOT be offered except on an isolated local link and flagged insecure: true in the descriptor (media.streams[].rtsp.insecure, transports.rest.insecure); conformance tests fail any device offering them by default.

13.3 Device authentication (device → client endpoint)Link to the section 13.3 Device authentication (device → client endpoint)#

A device MUST support at least one of:

Static shared passwords, HTTP Basic and HTTP Digest are NOT permitted.

13.4 Client authorization (client → device resources)Link to the section 13.4 Client authorization (client → device resources)#

Client-side identity (operator user, VMS service) is the client's concern, but UNIVIP scopes define what a client principal may do toward a device, and the device-side (or client-hosted endpoint) MUST enforce them:

Scopes are carried as the scope claim of a JWT access token (RFC 7519, RFC 9068) issued by the client's authorization server, or as an attribute in the mTLS certificate for machine clients. For requests forwarded through the session proxy, the client-hosted endpoint enforces its users' credentials and states their scopes in the request envelope; the device limits them to the scopes the operator allowed for that endpoint (Part 05 §5.5.1). In every case the client_id of the principal must match the session's verified client identity for status and lease envelopes to reach it (Part 05 §5.3.1). univip.vehicle MUST NOT be granted by default to any role that has univip.camera; the two MUST be separately assignable in the client's role model (Part 04 §4.4).

13.5 Message integrity and replayLink to the section 13.5 Message integrity and replay#

• Every envelope carries msg_id and timestamp; receivers MUST reject commands with issued_at older than 30 s (reason EXPIRED) or in the future by more than 5 s (clock skew allowance; reason INVALID_PARAMETERS), and MUST reject duplicate command_ids.
• Leases bind client_id; a command carrying a lease_id from a different authenticated client MUST be rejected with LEASE_SCOPE.
• Where MAVLink is used behind a gateway, MAVLink 2 signing SHOULD be enabled on the native link; it does not replace UNIVIP transport security.

13.6 Input validationLink to the section 13.6 Input validation#

Devices and clients MUST validate every received message against the schema named in its schema member before acting on it and MUST reject invalid messages with MALFORMED. Two kinds of schema failure do not make a message invalid (Part 01 §1.4, §1.5): a value outside an open enumeration, and a schema member naming another MINOR of the same MAJOR. Unknown non-must-understand members are ignored (Part 01 §1.4). Numeric ranges in schemas are normative.

13.7 PrivacyLink to the section 13.7 Privacy#

Position history is personal and operational data. Clients MUST apply the same access control and retention policy to telemetry as to the associated video. Devices MUST NOT publish operator personal data in telemetry; operator_user appears only in lease and audit records.

13.8 Logging and auditLink to the section 13.8 Logging and audit#

See Part 11 §11.7 for control audit. Authentication failures, lease events and configuration changes MUST be logged by both sides with device_id, client_id, timestamp and outcome. On the media plane, DTLS handshake and certificate-verification failures MUST be logged; unauthenticated STUN and other transport noise MAY be rate-limited or logged at a lower level so that it cannot flood the log.

13.9 Key rotation and revocationLink to the section 13.9 Key rotation and revocation#

Device credentials MUST be rotatable without changing device_id. Clients MUST support revoking a device credential, after which the device's sessions are closed with UNAUTHORIZED and reconnection fails until re-enrollment.

13.10 Comparison with ONVIF security (Informative)Link to the section 13.10 Comparison with ONVIF security (Informative)#

See ../docs/onvif-comparison.md for a side-by-side discussion. In short: UNIVIP mandates TLS 1.3 everywhere, forbids password-digest and HTTP Digest schemes, uses standard OAuth 2.0/mTLS identity, encrypts media by construction (DTLS-SRTP), and adds a lease-based authority model that has no ONVIF equivalent because fixed cameras do not move.