Security & Trust

Learn about Keymint's cryptographic controls, transport protections, session verification handshakes, and organizational compliance.

Keymint's infrastructure is built from the ground up around data isolation, secure cryptographic verification, and the principle of least privilege. This document outlines the security architecture and compliance safeguards implemented across the platform.

Cryptographic Controls

Keymint employs industry-standard cryptographic algorithms to protect licensing credentials and ensure execution bounds are tamper-proof.

1. Data at Rest & in Transit

Transport Security: All communication with the Keymint REST API, dashboard, and webhooks is strictly encrypted in transit using TLS 1.3 (with secure TLS 1.2 fallback). We enforce HTTP Strict Transport Security (HSTS) on all endpoints.
Storage Security: Customer data records and operational databases are encrypted at rest using AES-256. License key strings are stored as cryptographic hashes (SHA-256) to ensure they cannot be exfiltrated via raw database reads.

2. Offline License Signatures (Ed25519)

Offline license keys are generated as JSON Web Tokens (JWT) signed using asymmetric cryptography:

Signing Key Isolation: Private keys used for license signing are generated and stored in a secure cloud Key Management Service (KMS) and decoupled from standard operational tables.
Local Verification: Client applications store only the trusted public verification keys locally. The client extracts the Key ID (kid) from the incoming .lic header, retrieves the corresponding public key, and verifies the Ed25519 signature locally using standard libraries (such as jose). No internet access is required.

Session Hardening & Replay Defenses

Floating concurrent licenses require constant communication between client devices and the Keymint servers. To prevent seat theft, hijacking, and spoofing, we enforce a strict cryptographic challenge-response protocol:

Session Secret Exchange: Upon checking out a seat (POST /key/checkout), the client receives a temporary, cryptographically secure sessionSecret and an initial single-use challenge nonce (nextNonce).
HMAC-SHA256 heartbeats: Every heartbeat and check-in request must be signed. The client computes an HMAC-SHA256 signature using the sessionSecret over a payload containing the sessionId and the nextNonce.
Nonce Rotation: The server rotates the cryptographic nonce (nextNonce) with every successful heartbeat response. The previous nonce is instantly invalidated, preventing replay attacks.
Clock-Drift Protections: In addition to nonce rotation, the server validates timestamps to reject heartbeats with clock drift exceeding 15 minutes.

Access Control & Scoped Authorization

API access to Keymint is governed by role-based API keys and organization-level tenant isolation.

Organization Tenant Isolation

Every database query is strictly scoped to the authenticated organization. Cross-tenant queries are blocked at the router layer, preventing Insecure Direct Object Reference (IDOR) vulnerabilities.

API Key Scopes

We enforce the principle of least privilege. API keys can be configured with granular scopes using a bitmask mapping:

Scope	Allowed Operations	Typical Use Case
`admin`	Full read/write access to all products, customers, and license key records.	Backend management scripts and CI pipelines.
`client`	Activation, optional first-time licensee claim, device-scoped deactivation, checkout, heartbeat, and checkin. Blocked from detailed key lookup and administrative reads/writes.	Integration inside client-side SDK bundles.
`read-only`	View-only queries. Cannot create, modify, or delete.	Internal monitoring dashboards and telemetry tools.

API keys support optional expiration limits (30, 60, or 90 days). Expired keys are rejected at the gateway layer immediately.