ANKASecure© — Crypto Agility Orchestration Platform

Transforming cryptographic change from disruptive engineering projects into controlled, policy-driven operations.

How It Works

Most platforms force your application to specify a cryptographic algorithm directly. ANKASecure© inverts that model.

Your application references a kid (Key ID). The platform resolves the algorithm, key material version, hybrid configuration and policy constraints dynamically at runtime.

App references `kid`
  → Platform maps: kid → algorithm + material version + execution engine
  → Policy enforces: hybrid requirements, jurisdiction rules, lifecycle state
  → Result: cryptographic operation executed — algorithm invisible to caller

When your organization needs to migrate from AES-256 to a composite ML-KEM + AES hybrid, you update a policy — not your application code. The algorithmUsed field on every crypto response tells you what was actually selected, so audit and telemetry stay accurate.

The 5 APIs at a glance

The platform exposes five modular API groups, each documented in its own reference section on this portal:

Total surface: 422 endpoints, all sharing a single Bearer JWT.

Authentication

All API calls require a Bearer JWT in the Authorization header. Tokens are issued by the Auth API following OAuth 2.0 (RFC 6749) — the token endpoint accepts application/x-www-form-urlencoded bodies (not JSON) with these grant types:

• client_credentials — for workloads / apps (server-to-server)
• password — for human admins logging in
• refresh_token — for renewing an existing session
• urn:ietf:params:oauth:grant-type:token-exchange (RFC 8693) — for delegation / impersonation

Get a token — workload example

curl -s -X POST https://staging.ankatech.co/api/v3/auth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=550e8400-e29b-41d4-a716-446655440000" \
  --data-urlencode "client_secret=••••••••••••••••••••••••••••••••"

Response:

{
  "access_token": "eyJ...",
  "token_type":   "Bearer",
  "expires_in":   36000
}

Use the token on every request

Authorization: Bearer eyJ...

Two audiences, two roles for your token — pick the right grant for each concern:

A password token cannot call the crypto endpoints, and a client_credentials token cannot call the admin endpoints — the platform separates the provisioning plane from the runtime plane. Real integrations typically hold both: an admin identity that provisions keys, and one or more application identities that encrypt / decrypt with them.

Tokens are scoped to a tenant and carry a role's permissions. They are not transferable across environments or tenants.

Trying an endpoint from this portal? Click Try It on any operation, paste the access_token value in the auth prompt (ReadMe adds the Bearer prefix automatically), and the server default is already set to staging.ankatech.co.

Deep dive on grants, refresh, revocation, introspection, and error semantics: Authentication.

Permissions model

Permissions are role-based, not scope-parameter based. The token inherits whatever the identity's role grants — you cannot ask for extra permissions at token time.

There are 82 distinct permission strings in the current role catalogue. A few common ones:

Runtime cryptographic operations (/api/v3/crypto/encrypt, /decrypt, /sign, /verify) are granted by roles specific to your deployment — ask your admin for the role name that applies.

The full catalogue is exposed via GET /api/v3/admin/platform/scopes.

Quick Start (60 seconds)

Prereqs: a client_id + client_secret (UUIDs), a provisioned kid, all from your admin.

1. Authenticate

TOKEN=$(curl -s -X POST https://staging.ankatech.co/api/v3/auth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=<UUID>" \
  --data-urlencode "client_secret=<secret>" \
  | jq -r .access_token)

2. Encrypt (payload in Base64)

DATA_B64=$(printf '%s' 'sensitive data' | base64 -w0)

curl -s -X POST https://staging.ankatech.co/api/v3/crypto/encrypt \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{ \"kid\": \"<your-kid>\", \"data\": \"$DATA_B64\" }" | tee /tmp/enc.json

Response has jweToken (object), keyRequested, materialVersion, algorithmUsed.

3. Decrypt (pass the whole jweToken back)

JWE=$(jq -c .jweToken /tmp/enc.json)

curl -s -X POST https://staging.ankatech.co/api/v3/crypto/decrypt \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{ \"jweToken\": $JWE }" | jq

Response has decryptedData (Base64 — decode to verify).

The algorithm is resolved by the tenant's cryptographic policy. Your application never hardcodes it. Full walk-through in Quickstart.

Key types and algorithms

At create-key time (admin operation), you specify a kty (key type) and an algorithm. The tenant policy validates the combination and decides which material version to activate.

Common kty values:

purpose at create-key time is one of ENCRYPT_DECRYPT or SIGN_VERIFY — optional if the algorithm's keyOps disambiguates it, required otherwise.

Discover the full algorithm catalogue via GET /api/v3/algorithms — the endpoint returns every valid kty + algorithm combination the platform supports today.

Multi-Tenant Isolation

Every API call is automatically scoped to the tenant embedded in the JWT.

• Runtime endpoints (/api/v3/crypto/*) take no tenantId — it is derived from the token.
• Admin endpoints (/api/v3/admin/tenants/{tenantId}/…) take the target tenantId in the URL path; the platform enforces that your admin token has permission for that specific tenant.
• A client from Tenant A cannot read, use, or discover keys from Tenant B.
• Keys, policies, and audit logs are fully isolated per tenant.
• This isolation is architectural — it cannot be bypassed through any API parameter.

Audit Trail

Every state-changing operation — key create / rotate / revoke, policy change, encrypt / decrypt at the caller's option — emits an immutable audit event. The Audit API exposes 59 endpoints across 7 tags:

• Tenant Audit — queries for your tenant's audit trail
• Tenant Audit — Cryptographic Control Plane — key-lifecycle events specifically
• Meta-Audit — who queried the audit logs (audit of audit)
• Correlation Audit — trace a single transaction across tenants and services
• Audit Vocabulary — enumerate valid filter values
• Audit Integrity — verify the per-tenant hash chain (at-rest tamper detection)
• Platform Audit — cross-tenant analytics (platform admins only)

Post-Quantum Cryptography (PQC)

ANKASecure ships NIST-standardised PQC algorithms as first-class citizens:

• KEM: ML-KEM-512 / 768 / 1024 (FIPS 203, formerly Kyber)
• Signatures: ML-DSA-44 / 65 / 87 (FIPS 204, formerly Dilithium), Falcon, SLH-DSA (FIPS 205)
• Composite Hybrid: classical + PQC combined in a single JWE / JWS for zero-risk migration — COMPOSITE_KEM_COMBINE (encryption) and COMPOSITE_SIGNATURE (signing) with pairs like X25519+ML-KEM-768 or Ed25519+ML-DSA-65.

Two dedicated endpoints support PQC handshake negotiation for clients that need dynamic algorithm discovery — see PQC Handshake on the API Reference.

Error Responses

Non-auth endpoints follow RFC 7807 — Content-Type: application/problem+json:

{
  "type":     "https://api.ankatech.co/problems/key-not-found",
  "title":    "Key Not Found",
  "status":   404,
  "detail":   "Key 'my-key' does not exist for this tenant.",
  "instance": "/api/v3/crypto/encrypt"
}

Auth endpoints follow the OAuth 2.0 error format ({ "error": "invalid_grant", "error_description": "..." }) — see Authentication → Common errors.

Common HTTP codes:

Environments

Tokens issued in one environment are not valid in another. client_id / client_secret are environment-specific.

The Try It panel on every reference page defaults to staging.ankatech.co — you can switch to a Custom server for on-prem.

Full details: Environments & Credentials.

SDK & CLI

Java SDK (Maven Central — publish in progress)

<dependency>
  <groupId>co.ankatech</groupId>
  <artifactId>ankasecure-sdk-core</artifactId>
  <version>3.0.0</version>
</dependency>

Publishing to Maven Central under co.ankatech is in progress — until it lands, binaries are available on request.

CLI

An ankasecure CLI wraps the same endpoints for scripting — auth, crypto ops, key admin, streaming re-encryption. Consult your admin for the current binary and documentation.

What to Read Next

ANKASecure© | Crypto Agility Orchestration Platform | ANKATech Solutions INC