TRUST & SECURITY

Cryptographic and operational rigor, named and auditable.

We make exactly one promise on this page: every security claim points to a primitive or an audited control. We don’t use the word "unbreakable." We don’t use "military-grade." We name what we do and we cite where it’s documented.

Cryptographic primitives

Primitive Role
ChaCha20-Poly1305 Application-layer authenticated encryption (AEAD)
X25519 Ephemeral key exchange
HKDF-SHA256 Key derivation
SPIFFE / X.509 SVID Workload identity, rotated every 24h
QUIC + TLS 1.3 Transport (HTTP/2 fallback for restrictive networks)
Cosign Container image signing
Sliding-window replay protection Anti-replay at the Hub edge
Hand-drafted field-notebook page showing the Ewii cryptographic primitive matrix. Seven rows: ChaCha20-Poly1305 (Application-layer AEAD · RFC 8439), X25519 (Ephemeral key exchange · RFC 7748), HKDF-SHA256 (Key derivation · RFC 5869), SPIFFE / X.509 SVID (Workload identity · 24h rotation · SPIFFE/SVID spec), QUIC + TLS 1.3 (Transport layer · RFC 9000 · RFC 8446), Cosign (Container image signing · Sigstore/Cosign), Sliding-window replay protection (Anti-replay at Hub edge · NIST SP 800-38D). Dashed leader lines from ChaCha20-Poly1305 and QUIC + TLS 1.3 rows point to right-margin callouts distinguishing APPLICATION-LAYER AEAD from TRANSPORT-LAYER AEAD. Corner crop marks and FIG. 1 figure number in lower-right.
FIG. 1 Cryptographic primitive matrix — seven named primitives, their roles, and canonical specifications.

Identity model

Ewii uses SPIFFE workload identity. Every Client and every Hub workload has a SPIFFE identifier (SPIFFE ID), backed by a short-lived X.509 SVID. SVIDs are issued by the tenant’s identity authority and validated by the Hub at every connection. There are no shared secrets, no static API keys, and no long-lived credentials in any deployment.

SPIFFE Attestation and mTLS SVID Validation Sequence Protocol-accurate swimlane sequence diagram showing SPIFFE workload attestation (SPIRE Agent issues X.509 SVID to Client Workload) followed by the mTLS handshake between the Client Workload and the Hub, with SVID presented as the client certificate. Forest-green validation marks at SVID issuance (message 2), Hub-side trust-bundle validation (message 4), and per-query revalidation (message 7). SPIFFE specification §4 · RFC 8446 §4.1. SPIRE AGENT (CUSTOMER-SIDE, BUNDLED IN CLIENT) CLIENT WORKLOAD (CUSTOMER-SIDE) HUB (OPERATOR-SIDE) WORKLOAD ATTESTATION REQUEST process attestation: kernel-mode signal of binary identity X.509 SVID ISSUED spiffe://{trust-domain}/ewii-client/{workload-id} ATTESTED CLIENT_HELLO + SVID mTLS handshake initiation; SVID presented as X.509 cert VALIDATE SVID AGAINST TENANT TRUST BUNDLE VALIDATED HUB_CERTIFICATE + SESSION_ESTABLISHED mutual auth complete APPLICATION QUERY (IDENTITY-BOUND) query carries SVID identity claim PER-QUERY REVALIDATION revocation takes effect on next request FIG. 2 — SPIFFE ATTESTATION & SVID VALIDATION SEQUENCE SPIFFE workload attestation · X.509 SVID issuance · mTLS handshake · per-query revalidation Source: SPIFFE specification §4 (SVID format) · RFC 8446 §4.1 (mTLS handshake)
FIG. 2 SPIFFE attestation and SVID validation sequence

Threat model summary

Our threat model assumes: (1) the relay is observable but compromised; (2) the operator’s Hub host is trusted but auditable; (3) the customer’s Client host is trusted to the same level as their database. Under those assumptions, Ewii guarantees confidentiality of payload data (defense-in-depth encryption), authenticity of every connection (SPIFFE), and replay-resistance (sliding-window). The full threat model document is in the Trust Center pack.

Compliance posture

Canadian Protected B-aligned. ITSG-33 control mapping available. SOC-2-style controls documented for the relay infrastructure. CAIQ-Lite and SIG-Lite questionnaires pre-answered in the Trust Center pack. PCI-DSS scope analysis available on request. HIPAA/PHIPA mapping documented; we enter into BAAs with healthcare operators on request.

Vulnerability disclosure

Our Vulnerability Disclosure Policy is documented in the Trust Center pack. Machine-readable metadata: /.well-known/security.txt (RFC 9116). To report a vulnerability, email security@delta-telematics.ca with details. We acknowledge within one business day and we coordinate disclosure timing.

Researcher acknowledgements

We publicly recognize security researchers who report valid issues. No researcher has been listed yet — this section becomes a roll as we receive valid disclosures.

Trust Center pack

A single PDF + JSON manifest containing the full SOC-2-style control mapping, sub-processor list, vulnerability disclosure policy, cryptographic primitive matrix, threat model summary, Canadian sovereignty attestation, and pre-answered CAIQ-Lite / SIG-Lite questionnaires.

Machine-readable companion (for procurement automation, openly served): /trust-center-manifest.json.

Three fields

A work address. Free-mail addresses are filtered.

We email the link from hello@ewii.delta-telematics.ca. We do not subscribe you to anything.

Want a security-led conversation?

Schedule an Architecture Review