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 Key ID. The platform resolves the algorithm, hybrid configuration, lifecycle state, and policy constraints dynamically at runtime.

App references Key ID
  → Platform maps: Key ID → Algorithm Family → 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.

Authentication

All API calls require a Bearer JWT. Applications authenticate using client credentials — a clientId and clientSecret issued by the platform administrator for your tenant.

Obtain a token

curl -s -X POST https://<host>/api/v3/auth/token \
  -H "Content-Type: application/json" \
  -d '{
    "grantType": "client_credentials",
    "clientId": "your-client-id",
    "clientSecret": "your-client-secret"
  }'

{
  "accessToken": "eyJ...",
  "tokenType": "Bearer",
  "expiresIn": 3600
}

Use the token on every request

Authorization: Bearer eyJ...

Tokens are scoped to a tenant and carry the permissions granted to the client application. They are not transferable across environments or tenants.

Scopes

Scope	Permission
`crypto.encrypt`	Encrypt using keys assigned to the caller
`crypto.decrypt`	Decrypt
`crypto.sign`	Sign data
`crypto.verify`	Verify signatures
`crypto.keys.read`	List and inspect keys available to the caller
`crypto.keys.create`	Create keys
`crypto.keys.rotate`	Rotate keys

API Reference

Cryptographic Operations

Method	Endpoint	Scope required	Description
`POST`	`/api/v3/crypto/encrypt`	`crypto.encrypt`	Encrypt a payload using a key ID
`POST`	`/api/v3/crypto/decrypt`	`crypto.decrypt`	Decrypt a payload
`POST`	`/api/v3/crypto/sign`	`crypto.sign`	Sign data — classical, PQC, or composite hybrid
`POST`	`/api/v3/crypto/verify`	`crypto.verify`	Verify a digital signature
`POST`	`/api/v3/crypto/reencrypt`	`crypto.encrypt` + `crypto.decrypt`	Re-encrypt under a new key — no plaintext exposure
`POST`	`/api/v3/crypto/reencrypt/stream`	`crypto.encrypt` + `crypto.decrypt`	Streaming re-encryption for large files (multi-GB)

Key Management

Method	Endpoint	Scope required	Description
`POST`	`/api/v3/crypto/keys`	`crypto.keys.create`	Create a key (classical, PQC, or composite hybrid)
`GET`	`/api/v3/crypto/keys`	`crypto.keys.read`	List keys available to the caller
`GET`	`/api/v3/crypto/keys/{keyId}`	`crypto.keys.read`	Get key metadata and algorithm configuration
`POST`	`/api/v3/crypto/keys/{keyId}/rotate`	`crypto.keys.rotate`	Rotate a key — zero-downtime, backward-compatible
`POST`	`/api/v3/crypto/keys/{keyId}/revoke`	`crypto.keys.rotate`	Revoke a key immediately

Quick Start

Step 1 — Authenticate

curl -s -X POST https://<host>/api/v3/auth/token \
  -H "Content-Type: application/json" \
  -d '{
    "grantType": "client_credentials",
    "clientId": "acme-app",
    "clientSecret": "••••••••"
  }'

Step 2 — Create a key

curl -s -X POST https://<host>/api/v3/crypto/keys \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "keyId": "customer-data-key",
    "type": "COMPOSITE_HYBRID",
    "securityLevel": "HIGH"
  }'

{
  "keyId": "customer-data-key",
  "type": "COMPOSITE_HYBRID",
  "algorithm": "ML-KEM-768+AES-GCM-256",
  "status": "ACTIVE",
  "createdAt": "2026-04-13T10:00:00Z"
}

The algorithm is resolved by the tenant's cryptographic policy. Your application never hardcodes it.

Step 3 — Encrypt

curl -s -X POST https://<host>/api/v3/crypto/encrypt \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "keyId": "customer-data-key",
    "plaintext": "sensitive payload"
  }'

{
  "ciphertext": "BASE64_ENCODED_CIPHERTEXT",
  "keyId": "customer-data-key",
  "algorithm": "ML-KEM-768+AES-GCM-256",
  "correlationId": "req-abc-123"
}

Step 4 — Decrypt

curl -s -X POST https://<host>/api/v3/crypto/decrypt \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "keyId": "customer-data-key",
    "ciphertext": "BASE64_ENCODED_CIPHERTEXT"
  }'

{
  "plaintext": "sensitive payload",
  "keyId": "customer-data-key",
  "correlationId": "req-abc-124"
}

Key Types

Type	Algorithm families	Typical use
`SYMMETRIC`	AES-GCM-256, ChaCha20-Poly1305, Camellia-GCM	Bulk data encryption
`ASYMMETRIC_CLASSICAL`	RSA-OAEP, ECDSA, Ed25519	Signatures, asymmetric encryption
`POST_QUANTUM`	ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+)	PQC-only workloads
`COMPOSITE_HYBRID`	Classical + PQC combined — e.g. ML-KEM-768 + AES-GCM-256	Hybrid transition — recommended

125+ algorithms across 21+ families. The algorithm is never specified in your API call — it is resolved by policy.

SDK & CLI

Java SDK

ANKASecureClient client = ANKASecureClient.builder()
    .baseUrl("https://<host>")
    .clientId("acme-app")
    .clientSecret("••••••••")
    .build();

// Create a key
client.keys().create(KeyRequest.composite("customer-data-key", SecurityLevel.HIGH));

// Encrypt
EncryptResponse resp = client.crypto()
    .encrypt(EncryptRequest.of("customer-data-key", plaintextBytes));

// Decrypt
byte[] plaintext = client.crypto()
    .decrypt(DecryptRequest.of("customer-data-key", resp.getCiphertext()));

CLI

# Authenticate
ankasecure auth login --client-id acme-app --client-secret ••••••••

# Create a key
ankasecure keys create --key-id customer-data-key --type COMPOSITE_HYBRID

# Encrypt a file
ankasecure encrypt --key customer-data-key --input data.bin --output data.enc

# Decrypt
ankasecure decrypt --key customer-data-key --input data.enc --output data.bin

# Stream re-encrypt a large archive
ankasecure reencrypt \
  --source-key legacy-aes-key \
  --target-key pqc-composite-key \
  --input archive.bin \
  --output archive-pqc.bin

Error Responses

All errors 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 'customer-data-key' does not exist for this tenant.",
  "instance": "/api/v3/crypto/encrypt"
}

Status	Meaning
`400`	Invalid request — see `detail` for field-level validation errors
`401`	Missing, expired, or invalid JWT
`403`	Insufficient scope for this operation
`404`	Key or resource not found in this tenant
`409`	Conflict — e.g., key ID already exists
`412`	Key lifecycle state prevents this operation — key may be revoked or expired

Multi-Tenant Isolation

Every API call is automatically scoped to the tenant embedded in the JWT. There are no tenant parameters in requests.

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.

Environments

Environment	Base URL	Notes
Staging	`https://demo.ankatech.co`	Mirrors production

Tokens issued in one environment are not valid in another. clientId and clientSecret credentials are environment-specific.

What to Read Next

Goal	Section
Full request/response schemas	API Reference
Step-by-step integration walkthrough	Guides → Quick Start
Composite and hybrid key patterns	Guides → Composite Keys
Streaming large files	Guides → File Operations
Java SDK setup	Guides → Java SDK
CLI command reference	Guides → CLI