Integration security

DYCRYPT uses asymmetric signatures so your application needs only a public key or certificate. That public material can verify licences but cannot mint them.

What belongs in your application

• the product public key or certificate;
• the stable product key your build accepts;
• the complete customer licence;
• the issuer URL and organisation slug for Online or Hybrid;
• the product’s check id and check token, which authenticate the check endpoint;
• application-owned state for the most recent successful check when required by your SDK integration.

Never embed a private signing key, HSM PIN, platform password, or organisation API token in the licensed application.

Why a check answer can be trusted

The check token is the one credential that does belong there, and it is scoped to exactly that: calling one product’s check endpoint. It cannot read, issue, or manage anything. Because it ships inside what you distribute, treat it as identifying rather than secret — the signed receipt, not the token, is what makes a check answer trustworthy.

TLS protects the check request in transit. The receipt proves that DYCRYPT answered. The SDK verifies it with the product public key already embedded in your application, so a different server cannot reset the offline window by returning its own ACTIVE JSON.

Keep receipt verification enabled and do not make the issuer URL user-editable. If the configured issuer cannot produce a valid receipt, the check fails and the licence eventually reaches STALE under its signed timing rules.

Integration checklist

• Check the exact prd product key; a valid licence for another product must not unlock this one.
• Reject unsupported claims versions instead of ignoring restrictions from a newer format.
• Let the SDK verify before exposing or enforcing claims.
• Treat STALE as a reconnect path, not as proof of tampering.
• Use TLS for Online and Hybrid checks, and keep receipt verification on. TLS protects the request in transit; the receipt is what proves DYCRYPT answered.
• Do not make the issuer URL user-editable. A configurable endpoint plus a disabled receipt check is a documented bypass.
• Protect persisted last-check state from ordinary user modification.
• Test clock boundaries, network loss, machine changes, and hostile input.

Client-side limits

Machine binding raises the cost of casual licence sharing, and signed answers mean a fake issuer cannot grant it. A determined attacker who controls a machine can still modify your application and remove its checks. Protect high-value server-side capabilities with server-side authorization as well.

Signing-key choices

DYCRYPT protects signing keys and supports Ed25519, RSA, and elliptic-curve algorithms with public keys or X.509 certificates. DYCRYPT Sovereign can sign through your HSM or PKCS#11 token when private keys must remain on dedicated hardware.

See Application fingerprinting for the machine data collected by each SDK.