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 Full Online or Hybrid;
• 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 API token in the licensed application.

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 Full Online and Hybrid checks.
• 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. A determined attacker who controls a machine can 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. Enterprise on-premises deployments can include custom HSM or PKCS#11 integration when private keys must remain on dedicated hardware.

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