Frequently asked questions

Audience: anyone evaluating, integrating with, or operating ANKASecure©.

How to use this page: browse by category or search the page (Ctrl+F). Each answer points to the canonical documentation for deeper detail.

Categories

1. Platform and architecture essentials
2. Cryptographic capabilities
3. Key management and lifecycle
4. HSM integration
5. Compliance and regulatory
6. Performance and scalability
7. Deployment and operations
8. Migration and interoperability
9. SDK, CLI, and integration
10. Policy engine

1. Platform and architecture essentials

What is ANKASecure© and how does it differ from AWS KMS or Azure Key Vault?

ANKASecure© is a complete post-quantum cryptography platform — microservices, SDKs, CLIs, and admin tooling — versus AWS KMS / Azure Key Vault which are key management services.

Key differences:

• Composite hybrid keys — production-ready AND-decrypt (AWS/Azure roadmap only)
• Regional algorithms — China (GMT), Russia (GOST), South Korea (KISA), Japan (CRYPTREC)
• Deployment — on-premise option (AWS/Azure cloud-only)
• APIs — standards-based (RFC 7516/7515) versus proprietary
• Streaming — no API size limit (vs API-imposed size limits); a proxy in front of the deployment may cap uploads; see Behind a buffering proxy

Use ANKASecure© for: PQC migration today (not roadmap), regional market access, on-premise requirements, avoiding vendor lock-in.

How many algorithms does ANKASecure© support and what standards does it cover?

Comprehensive algorithm catalog covering simple primitives and composite hybrid combinations across PQC KEMs, PQC signatures, classical PKI, symmetric AEAD, and MAC families. Standards coverage spans the major international and national bodies: NIST, ISO/IEC, IETF, ENISA, BSI, ANSSI, ETSI, CRYPTREC, GMT, KISA, MySEAL, NSA, GOST, NCA-NCS.

The complete current catalog is queryable at runtime via GET /api/v3/key-management/supported-algorithms and documented in Algorithm Reference.

What is crypto-agility and why does it matter?

Crypto-agility is the ability to change cryptographic algorithms without modifying application code.

How it works: applications reference key identifiers (KID) like production-key-001, while the platform resolves the actual algorithm (RSA-2048, ML-KEM-768, etc.) via configuration.

Benefits:

• Immediate response to vulnerabilities — algorithm change is a policy update, not a coordinated engineering effort
• Frictionless modernization — algorithm upgrades absorb into routine operations
• Single source of truth — uniform cryptographic posture across the enterprise vs divergent per-team implementations
• Continuous regulatory alignment — adapt to evolving mandates without redesign

For the deeper treatment, see Pillar 1 — Crypto-Agility and Policy-Driven Crypto-Agility.

Can you explain the high-level architecture in simple terms?

ANKASecure© uses a microservices architecture with ten Spring Boot microservices, the React-based Admin Console, and a shared infrastructure layer:

All services communicate via encrypted overlay networks; state is external (PostgreSQL / Redis), enabling horizontal scaling.

For the architectural reasoning behind this split, see The Cryptographic Control Plane.

Is ANKASecure© a library, a service, or something else?

ANKASecure© is a complete platform.

Deployment models: SaaS (ANKATech-managed), Private Cloud (customer-managed, in the customer's cloud) and On-premise (full customer control, air-gapped supported). A customer may run on-premise and private-cloud environments side by side; that is a topology within the three models, not a fourth model.

Unlike libraries (OpenSSL, Bouncy Castle): ANKASecure© provides turnkey infrastructure. Unlike cloud services (AWS KMS): on-premise option and standards-based APIs (no vendor lock-in).

What are the five pillars and why do they matter?

The CAPA framework (Crypto Agility Posture Architecture) defines five foundational pillars:

1. Crypto-Agility — cryptographic change without application change
2. Cryptographic Sovereignty — retain control of cryptographic trust, choice and authority wherever your data operates
3. Frictionless Modernization — modernize the cryptography protecting your data without recreating the data or rewriting the applications
4. Cryptographic Governance & Compliance — turn cryptographic requirements, including regulatory ones, into enforceable policy and verifiable evidence
5. Enterprise Readiness — cryptographic infrastructure interoperates with the enterprise rather than requiring the enterprise to adapt around it

Together they enable the operation of a Cryptographic Control Plane capable of supporting continuous cryptographic evolution. See The CAPA framework for the dedicated treatment.

2. Cryptographic capabilities

What is streaming encryption and what are the limits?

Streaming encryption processes files in 8 KB chunks with constant memory regardless of file size — tested with multi-TB files.

Key characteristics:

• Endpoints — POST /api/v3/crypto/stream/encrypt, /api/v3/crypto/stream/decrypt
• Memory — constant; no file-size limit
• Format — detached JWE (General-JSON header < 1 KB plus binary ciphertext, no Base64 expansion)
• Throughput — network/disk-bound

Streaming versus compact:

"No API limit" is the API's own bound; a proxy in front of the deployment may cap uploads; see Behind a buffering proxy.

For how a client chooses between the two, see File Operation Patterns.

How does re-encryption work without exposing plaintext?

Re-encryption uses a streaming algorithm that never exposes the full plaintext:

while (chunk = read(8KB)) {
    plaintext_chunk = decrypt(chunk, oldKid);
    ciphertext_chunk = encrypt(plaintext_chunk, newKid);
    write(ciphertext_chunk);
    zeroize(plaintext_chunk);
}

Security characteristics:

• Ephemeral plaintext — 8 KB chunks only, very short lifespan
• Immediate zeroization — Arrays.fill(0) after each chunk encryption
• Never persisted — not written to disk, logged, or transmitted

Benefits:

• Reduced attack surface compared to traditional decrypt-to-temp-file workflows
• No API size limit (tested multi-TB); a proxy in front of the deployment may cap uploads; see Behind a buffering proxy
• Zero-downtime — background re-encryption while applications remain operational

See File Operation Patterns for the streaming client surface, and Key Identifier (KID) System for how a ciphertext keeps naming the right key across a re-encryption.

What are composite / hybrid keys and when should I use them?

Composite keys combine classical (X25519, P-256/384/521) with post-quantum (ML-KEM, ML-DSA) algorithms.

Two modes:

• COMPOSITE_KEM_COMBINE (encryption) — the key is derived from BOTH component shared secrets by the NIST SP 800-227 key combiner, so decryption needs both, and the result stays secure as long as at least one component remains secure
• COMPOSITE_SIGNATURE (signatures) — one composite signature, valid only when the classical and the PQC components both verify

When to use:

• Federal acquisitions guided by the GSA PQC Buyer's Guide, which lists a hybrid approach as a transition consideration
• Long-term data (financial transactions, medical records, 10–20+ year retention)
• Critical infrastructure
• Defense-in-depth security

When not to use:

• Performance-critical streaming (composite has overhead vs simple keys)
• Short-lived data (session tokens, temporary credentials)
• Non-compliance scenarios where simple keys are sufficient

Standards alignment: composite keys align with the hybrid cryptographic algorithms that NIST CSWP 39 §3.2.4 describes (see NIST CSWP 39 Alignment — §3.2.4^*) and with the hybrid approach the GSA PQC Buyer's Guide §6.3 lists as a consideration; the traditional components use FIPS 186-5 curves; ML-KEM-1024 and ML-DSA-87, the NSA CNSA 2.0 public-key parameter sets, are offered standalone and in composite keys.

For deeper treatment: Hybrid vs Composite Keys, the Composite Algorithm Catalog, and SDK Flow 18 for a runnable example.

Are ANKASecure©'s formats JOSE-compliant and interoperable?

Compliance varies by key type:

Interoperability:

• ANKASecure© ↔ ANKASecure© — full
• ANKASecure© → standard JOSE library — parse-only (cannot decrypt composite without SDK)
• Standard → ANKASecure© — full

Mitigation strategies for interop with non-ANKASecure© systems: provide the SDK to partners, export individual components as standard JWKs via the migration API, and rely on the private header parameters (anka_kdf in the protected header) being ignored by standard libraries. A composite JWE carries no shared unprotected header, and no standard JOSE library can derive its content key.

For more on interoperability patterns, see Interoperability & Standards and JOSE Technical Reference.

What AEAD and integrity guarantees does ANKASecure© provide?

All encryption uses AEAD (Authenticated Encryption with Associated Data): AES-256-GCM with a 16-byte authentication tag.

AAD binding includes:

• tenantId — prevents cross-tenant attacks
• kid — prevents key swapping
• algorithm — prevents algorithm confusion
• keyOps — enforces usage policy
• createdAt — replay attack detection

Integrity guarantees: any ciphertext modification fails tag validation and aborts decryption; different tenantId produces tag mismatch; NIST SP 800-38D wire format is followed.

For composite keys, each component is independently wrapped with unique AAD, preventing component-level attacks.

Can I query the available algorithms dynamically?

Yes. GET /api/v3/key-management/supported-algorithms returns the full catalog with metadata: kty (one of the twenty-one published key-type tokens — COMPOSITE for every hybrid pairing), compositeMode (COMPOSITE_KEM_COMBINE / COMPOSITE_SIGNATURE, composite entries only), alg, keyOps, status (RECOMMENDED / LEGACY / EXPERIMENTAL), sunsetDate, advisory, securityLevel (NIST L1/L3/L5), standards (ratifying bodies), category (CLASSICAL / POST_QUANTUM / HYBRID).

CLI filtering supports: --kty, --alg, --category, --status, --key-ops, --security-level, --min-security-level, --max-security-level, --standards, --composite-mode, --format, --count.

Use cases: runtime algorithm selection without hardcoding, verification of availability before key generation, discovery of PQC migration paths through the advisory field, and policy-aware applications.

3. Key management and lifecycle

How does key rotation work without re-encrypting all data?

ANKASecure© rotation is a stable-KID material-version advance — the kid never changes:

1. Rotation creates a new PRIMARY material version (vN+1), which may use a different algorithm within the same purpose family.
2. The previous version is demoted to RETIRED and retained, so historical data stays decryptable/verifiable.
3. The kid is unchanged: primaryMaterialVersion advances to vN+1, and the new version records rotatedFromVersion = vN.

Behavior:

Benefits: zero downtime (no re-encryption required), historical data continues to decrypt/verify with its originating version, new operations use the new PRIMARY version immediately. There is no new kid, no "successor key", and no nextKid/previousKid chain.

Optional: POST /api/v3/crypto/reencrypt converts old JWEs to the new PRIMARY version in the background, enabling retirement of superseded material versions.

Rotation cannot cross purpose families (an ENCRYPT_DECRYPT key stays ENCRYPT_DECRYPT; a SIGN_VERIFY key stays SIGN_VERIFY). See Key Identifier (KID) System for how versions are named and resolved.

What are the key states and when do transitions occur?

A key (the Stable KID) has exactly nine states. The wire token is the lower-case value the API returns in a key's status field, and it is the same value the status filter accepts.

Common transitions: active → rotated (on rotation), active → expired, active → suspended → active, archived → pending_destruction → deleted_logical, revoked → archived. Rotation advances the PRIMARY material version under the same kid; it never mints a new kid.

Notable property: REVOKED allows decrypt and verify (some competitors block all operations on revocation, causing data loss).

How is composite key lifecycle managed?

Composite keys follow the same states as simple keys but with additional validation constraints:

1. Mode immutability — COMPOSITE_KEM_COMBINE cannot change to COMPOSITE_SIGNATURE during rotation
2. Algorithm preservation — component algorithms must match exactly across rotations
3. Component count — must match (typically 2)
4. Atomic rotation — all components rotate together; no individual component rotation

Rotation endpoint: POST /api/v3/admin/tenants/{tenantId}/keys/{kid}/rotations with composite-specific validation.

Result: both components rotate atomically, maintaining quantum resistance throughout the lifecycle.

Can I import legacy keys from old systems?

Yes. POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore imports PKCS#12 (.p12, .pfx) and JKS (.jks) keystores.

Process:

1. Upload the keystore file as the keystore part of a multipart/form-data request
2. Provide the password (optional for unprotected stores)
3. Select validation mode (STRICT / IMPORT_ONLY / SKIP)
4. Choose KID generation strategy (AUTO appends alias, MANUAL uses explicit mappings)

Format detection is automatic via magic bytes. Multi-key bundles are extracted into individual keys with collision detection. All imported keys are wrapped with the HSM KEK (same security as native keys), tagged origin=IMPORTED, and marked restricted=true if expired (in IMPORT_ONLY mode).

What happens to keys with expired certificates?

Behavior depends on validation mode:

IMPORT_ONLY use cases: SOX, SEC Rule 17a-4, and similar regulations require ability to decrypt records even after the issuing certificate has expired. Medical records (50+ year retention) and financial archives (10–20 year retention) are typical scenarios.

Defense-in-depth: keyOps (JWT metadata) plus Policy (lifecycle rules) plus Status (EXPIRED enum) — triple enforcement.

4. HSM integration

Which HSM vendors are supported?

ANKASecure© supports multiple HSM vendors via a vendor-agnostic PKCS#11 interface (Java 25 FFM API):

Auto-detection identifies common providers from the PKCS#11 library in use; the provider can also be set explicitly in the deployment configuration.

For deeper HSM-vendor and integration detail, refer to the HSM Integration documentation in the security section.

Software HSM versus hardware HSM: trade-offs?

Recommendation: SoftHSM for development (identical API, dev-prod parity); hardware HSM for production. Migration path SoftHSM → CloudHSM staging → Luna production requires no application code changes — only the deployment's HSM module configuration changes.

Can SoftHSM be used in production?

Not recommended for compliance scenarios. SoftHSM lacks FIPS 140-2 certification, has no physical tamper protection (its token store is a set of files on the host), uses a software RNG, and has extractable keys.

Acceptable for: non-compliance scenarios (internal applications without regulatory requirements), cost-sensitive deployments, and rapid deployment without hardware procurement.

For compliance-bound deployments, use Luna / CloudHSM / nShield. PCI-DSS Requirement 3.6 mandates a hardware HSM.

How are KEKs managed and how does the cache hierarchy work?

Every tenant has its own KEK, on whichever backend that tenant resolves to. On a PKCS#11 HSM it is a key object generated with CKA_EXTRACTABLE=false; on a Cloud KMS backend it is a key that never leaves the service. Cryptographic isolation rests on that per-tenant KEK together with the AES-256-GCM AAD binding of tenantId and routing on the authenticated tenantId — not on key separation alone. On an ANKA-managed Edition tier, the HSM or KMS that holds the tier's per-tenant KEKs is operated by ANKATech for every tenant of that tier; each tenant's KEK remains its own. A tenant that needs sole control of the custody root brings its own backend (BYOK).

The reference to a tenant's KEK is cached at two levels:

Core API never invents a KEK reference of its own, and it never uses one it cannot verify: when a tenant's KEK reference cannot be resolved and verified, the operation is refused with a problem response and nothing is wrapped. Integrity is chosen over availability on purpose.

Propagation: when the Admin API provisions or changes a tenant's KEK, it publishes the signed reference and notifies every Core API instance, which discards its cached copy, so subsequent operations use the new KEK.

For deeper treatment of envelope encryption and KEK management, refer to the HSM Integration documentation in the security section.

How does ANKASecure© support FIPS 140 requirements?

ANKASecure©'s software is not FIPS 140 certified (it is a Java application, not itself a cryptographic module).

FIPS path for customers:

1. Use FIPS-certified HSMs (Luna, CloudHSM, nShield) — all have FIPS 140-2 Level 3 certificates
2. Use FIPS-approved algorithms (ML-KEM FIPS 203, ML-DSA FIPS 204, SLH-DSA FIPS 205, AES-GCM FIPS 197, RSA/ECDSA FIPS 186-5)
3. Use the Bouncy Castle FIPS edition

Customers requiring FIPS-aligned operation should deploy with FIPS-certified HSMs and enforce FIPS-approved algorithms via policy templates such as NIST_APPROVED.

5. Compliance and regulatory

What standards does ANKASecure© align with?

NIST: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), FIPS 186-5 (P-curves), CSWP 39-upd1 §3.2.4 (hybrid algorithms, descriptive), SP 800-227 (final, September 2025: the composite KEM of §4.6.1 and the approved key combiner of §4.6.2 behind the HKDF-SHA256/384/512 tokens).

FIPS: FIPS 140-2 Level 3 (HSM support), FIPS 197 (AES-256).

ETSI: TS 103 744 V1.2.1 (hybrid key establishment; the CatKDF and CasKDF combiners of §8.2.3 / §8.3.3, conformance claimed on the 10 §7.7.2 parameter sets, for EU telecom 5G/6G). HQC standardization at ETSI is IN PROGRESS — the platform records the ETSI attribution on HQC as a workstream, not a published deliverable.

Regional: BSI TR-02102-1 (Germany), ANSSI RGS v2 (France), ISO/IEC, OWASP REST API Security, GMT (China), CRYPTREC (Japan), KISA (South Korea), GOST (Russia).

For the regulatory dimension as a CAPA pillar, see Pillar 4 — Cryptographic Governance & Compliance. For the algorithm-level mapping, see Algorithm Reference.

Is ANKASecure© FedRAMP authorized?

ANKASecure© is not currently FedRAMP authorized. Current federal compliance posture:

A federal buyer can deploy ANKASecure© on premises (customer data center, customer controls the FedRAMP authorization boundary), with FIPS-validated HSMs and FIPS-approved algorithms enforced via the US_NSA_CNSA policy template.

How does ANKASecure© support PCI-DSS, HIPAA, and GDPR?

PCI-DSS — Requirement 3.6 (cryptographic key management) via FIPS 140 Level 3 validated HSMs (the HSM vendor's validation); Requirement 3 (protect stored cardholder data) via AES-256-GCM; Requirement 4 (protect transmitted data) via TLS 1.3 plus optional PQC transport.

HIPAA — §164.312(a)(2)(iv) (Technical Safeguards) via quantum-resistant algorithms; §164.308(b)(4) (PHI safeguards) via HSM key protection; multi-tenant isolation (cryptographic, not just access control).

GDPR — Article 32 (state-of-the-art encryption) via NIST PQC algorithms; Article 25 (data protection by design) via envelope encryption; soft-delete supports the right to erasure while preserving audit.

Audit trail: all operations logged with correlation IDs; multi-category logging with appropriate retention.

What about Common Criteria certification?

ANKASecure© is not currently Common Criteria certified. Customers requiring Common Criteria coverage can deploy ANKASecure© with Common Criteria-certified HSMs (Thales Luna has CC EAL4+ for the cryptographic module; nShield CC certifications are available). The HSM provides CC-certified key storage; ANKASecure© provides application-level cryptographic operations.

Which standards does ANKASecure© currently align with?

Current and production-deployed:

• NIST FIPS 203/204/205 (ML-KEM / ML-DSA / SLH-DSA)
• NIST CSWP 39 (crypto agility; hybrid cryptographic algorithms per §3.2.4)
• GSA PQC Buyer's Guide (considerations for PQC products, services and solutions)
• FIPS 186-5 (P-curves)
• NSA CNSA 2.0 parameter sets (ML-KEM-1024, ML-DSA-87)
• OWASP REST API Security
• ETSI TS 103 744 (hybrid key establishment); HQC standardization IN PROGRESS
• BSI TR-02102-1
• ANSSI RGS v2
• GMT (China), CRYPTREC (Japan), KISA (South Korea), GOST (Russia)

6. Performance and scalability

What is the throughput for different algorithm families?

Order-of-magnitude characteristics (vary by hardware and payload):

Performance bottleneck typically: network and serialization overhead vs pure crypto.

For up-to-date measured benchmarks, see Performance Benchmarks.

How many concurrent requests can ANKASecure© handle?

Concurrency is implemented with Java 25 Virtual Threads (Project Loom). Virtual threads:

• Park automatically during blocking I/O, releasing carrier threads
• Have very low memory footprint (approximately 1 KB per VT vs 1–2 MB traditional)
• Enable thousands of concurrent in-flight requests on a small carrier-thread pool

Horizontal scaling: the Core API keeps no state of its own, so capacity grows by adding replicas.

What is the performance for streaming large files?

Streaming operations have constant memory regardless of file size (tested multi-TB).

• Throughput — network/disk-bound (not CPU-bound)
• Latency — linear with file size

For comparison, compact operations require approximately 2× file size in memory, making them unsuitable for files larger than approximately 100 MB.

Streaming enables: database backups, video files, log archives, VM images, S3-to-S3 direct transformations, and similar large-data scenarios.

Does performance differ between ARM64 and AMD64 architectures?

Key observations: ARM64 ChaCha20 outperforms AES-GCM (no AES-NI dependency), PQC algorithms are platform-independent, and overall parity is approximately 95–105% for mixed workloads.

Recommendation: AMD64 for general workloads, ARM64 for cost-sensitive cloud (Graviton vs x86), and ARM64 for ChaCha20-heavy workloads (mobile backends, IoT gateways, VPN servers).

Multi-arch Docker images: a single deployment definition deploys to AMD64 or ARM64 automatically.

What are the resource requirements for production?

Sizing is part of the deployment documentation that accompanies a licensed deployment, because it depends on the deployment model. At a high level, a complete stack (microservices plus infrastructure) needs sufficient CPU and memory to run the full set comfortably with headroom for traffic spikes; dual-stack and triple-stack configurations exist for multi-environment deployments.

7. Deployment and operations

What deployment models are available?

The platform recognizes three deployment models, and they are the three values its deployment_type can take:

Migration paths: SaaS → Private Cloud or On-premise (export, deploy, import); Private Cloud ↔ On-premise for individual environments.

Decision drivers: data residency, own HSM or cloud KMS requirement, ops team size, time-to-production constraints.

How does the Docker Swarm architecture work?

Docker Swarm orchestrates the full set of services of an environment:

• Managers — one, or several for high availability
• Services — each microservice runs as a replicated Swarm service
• Networks — traffic between services travels on an encrypted network private to the environment, so environments (for example development, staging and production) are isolated from one another
• Secrets — managed by the orchestrator and encrypted at rest; never baked into an image
• Volumes — persistent storage for the platform's data

Stack lifecycle and scaling are performed by whoever operates the deployment: ANKATech's operations team on a SaaS subscription, your own infrastructure team on an enterprise install. Neither procedure is reproduced here, because both ship with the deployment and are maintained there — environment lifecycle covers deploying, restarting and rolling a stack without downtime, and horizontal scaling covers adding replicas to a service. Ask whoever operates your deployment for either one.

Can ANKASecure© run on multi-architecture clusters?

Yes. Docker multi-arch images support heterogeneous clusters: an AMD64 manager with ARM64 workers, for example. Swarm schedules services based on architecture constraints in the deployment definition. Performance is approximately equivalent across architectures for mixed workloads.

How are monitoring and alerting configured?

Metrics — Micrometer OTLP registry → OTel Collector → any OTLP-compatible backend (Grafana Cloud, Datadog, New Relic, Dynatrace).

Logging — Structured JSON (Logback + Logstash encoder), multi-category (app, audit, usage, license, auth), Fluent Bit ingestion into OpenSearch, with size/age rollover and retention tiers.

Health checks — Spring Boot Actuator probes via /actuator/health/liveness and /actuator/health/readiness on per-service management ports.

Correlation IDs — UUID per request via X-Correlation-ID header, propagated across microservices for distributed debugging.

What is the backup and restore procedure?

Backup and restore are operator procedures, run by whoever operates the deployment: ANKATech's operations team on a SaaS subscription, your own infrastructure team on an enterprise install.

A backup is hot: it runs while the environment is up and captures its configuration together with a consistent capture of the platform databases. What it guarantees:

• Sealed, never plaintext. Every file a backup produces is signed and encrypted to the host key and to an offline escrow key, and no plaintext copy of the archive is ever written to disk.
• Secrets travel apart from the archive. The secrets that cannot be regenerated travel in their own sealed payload, and local HSM token material, when the environment holds any, in a third. The archive alone restores nothing.
• Verified before it is opened. The archive's digest is signed inside the secrets payload, and a restore checks it before opening anything. A restore refuses an archive that is not sealed; there is no unverified path.
• Cache data is not backed up. A restored environment rebuilds it from the database, and every user signs in again.
• Regenerable secrets are minted fresh on restore, so applications re-authenticate against the new token-signing keys.

For the full custody model and the procedure, see Backup and Restore^*.

Backup schedule defaults to daily automated cron; retention is configurable. Disaster recovery (decompress, regenerate secrets, re-deploy stack, verify health) takes approximately 30–60 minutes for a full environment.

8. Migration and interoperability

Can I import PKCS#12 and JKS keystores?

Yes. POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore supports both PKCS#12 (.p12, .pfx) and JKS (.jks) with automatic format detection. Multi-key bundles are extracted into individual keys with collision detection. Certificate chains (Root CA, Intermediate CA, End Entity) are imported. A staged validation pipeline runs structural, key-binding, temporal, CA expiration, chain signature, optional PKIX trust anchor, and extension checks. All imported keys are HSM-protected with the same envelope encryption as native keys.

How do I convert legacy PKCS#7 / S/MIME files to modern JOSE?

In steps.

Step 1 — Analyze: POST /api/v3/migration/analyze-pkcs7 introspects the structure (SignedData, EnvelopedData, SignedAndEnvelopedData), lists every signer and recipient, and names every key the conversion needs. It needs no key.

Step 2 — Import keys: POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore imports, with its private key, a key for every actor: each signer, the recipient that decrypts (a key that decrypts and encrypts), and every other recipient (a key admissible to encrypt — a keystore import with its private key, or the encryption key of a DUAL import). Current limitation: a certificate imported alone is a verify-only trust anchor and is refused as a signer or a recipient.

Step 3 — Convert: POST /api/v3/migration/convert-pkcs7-to-jose transforms to JWE/JWS with the same classical keys: the content is re-signed (PS256 for RSA; ES256/ES384/ES512 or ESB256/ESB384/ESB512 for EC, by curve) and re-encrypted (A256GCM, with RSA-OAEP-512 key management for RSA recipients). Every signer and every recipient is carried: one signer and one recipient at most yield the Compact serialization, several yield the General JSON serialization (one signature per signer, one recipient entry per recipient).

Optional Step 4 — PQC upgrade: POST /api/v3/crypto/resign (RSA → ML-DSA), POST /api/v3/crypto/reencrypt (RSA → ML-KEM). A result addressed to several keys is accepted too: re-sign verifies every signature and replaces only the rotated one, and re-encrypt draws a fresh content-encryption key and replaces only the rotated recipient, both named by sourceKid. A signer or recipient known only by its certificate is not convertible in the first place — see Actors known only by a certificate.

Current limitations: RFC 3161 timestamps in the input are detected but not validated, and signer certificates are not PKIX path-validated (every re-signed signer's CMS signature is verified).

The streaming variants, POST /api/v3/migration/stream/analyze-pkcs7 (operationId analyzePkcs7Stream) and POST /api/v3/migration/stream/convert-pkcs7-to-jose (operationId convertPkcs7ToJoseStream), handle larger files.

What are realistic migration timelines for RSA → PQC?

Timeline depends on deployment size:

Decision factors: application count, risk tolerance, uptime requirements, compliance deadlines.

ANKASecure©'s contribution: zero code changes (configuration-driven), and the actual platform-side migration is a policy update of minutes — the timelines above reflect organizational validation and testing, not platform limitations.

For the framework that organizes this migration, see The Cryptographic Maturity Model and Pillar 3 — Frictionless Modernization.

Can ANKASecure© coexist with our existing KMS (AWS, Azure, HashiCorp Vault)?

Yes. ANKASecure© complements existing KMS rather than replacing them. Patterns:

• Dual-KMS — ANKASecure© for PQC operations, existing KMS for classical
• Gradual migration — new applications use ANKASecure©, legacy continues with existing KMS
• Interoperability — utility operations (verify signatures from KMS, encrypt for KMS recipients) without requiring keystore import
• Unified — migrate all keys to ANKASecure©, retire the old KMS

Coexistence is sustainable indefinitely; organizations frequently run dual-KMS for years during gradual migration.

What about migrating S/MIME email archives to PQC?

S/MIME uses PKCS#7 format. Process:

1. Extract S/MIME signing keys from email-client keystores; import via POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore
2. For each email: analyze-pkcs7 introspects, convert-pkcs7-to-jose transforms to JWS (Compact for one signer, General JSON for several)
3. Optional: resign to replace RSA with ML-DSA-65
4. For large archives, use streaming variants and a checkpoint/resume pattern

9. SDK, CLI, and integration

Which SDKs and tools are available?

Current:

• Java SDK — Maven Central (co.ankatech:ankasecure-sdk), Android support
• Java Key Management SDK — Maven Central (co.ankatech:ankasecure-key-management-sdk)
• Crypto CLI — encryption, signatures, key management, streaming, PKCS#7 migration; multi-platform installers (Windows .exe/.zip, macOS .dmg, Linux .sh/.deb)
• Key Management CLI (ankasecure-km) — keys, rotation, destruction requests and grants of one tenant, as an administrative workload

REST APIs: OpenAPI 3.0, Swagger UI at /swagger-ui.html.

Non-JVM applications integrate via the REST API directly using the OpenAPI 3.0 specification.

For deeper treatment, see the SDK Overview and the Crypto CLI.

What are the CLI modes (interactive, guided, batch)?

Interactive mode (--interactive or -i) — menu-driven with index-based selection (no UUID copy-pasting), multi-step wizards, breadcrumb navigation, type-to-confirm safety on destructive actions. Significantly reduces learning curve and eliminates syntax errors.

Guided mode (Crypto CLI specific) — step-by-step prompts for complex operations such as composite key generation; selects regulatory templates and configures limits.

Batch mode (default, command-line syntax) — traditional CLI suitable for automation; JSON output for piping to jq.

All commands are accessible in all modes.

How do I integrate with REST APIs programmatically?

Java applications — use the SDK (thread-safe sharing across thousands of threads, automatic token refresh, optional transparent PQC transport):

AnkaSecureSdk factory = new AnkaSecureSdk(props);
AuthenticatedSdk sdk = factory.authenticateApplication(clientId, clientSecret);
EncryptResult result = sdk.encrypt("my-key", plaintext);

Other JVM languages (Kotlin, Scala) — OpenAPI Generator produces type-safe clients from /v3/api-docs.

Non-JVM (Python, Go, JavaScript, .NET, etc.) — REST API integration: POST /api/v3/auth/token to obtain a JWT, then Authorization: Bearer for crypto endpoints. OpenAPI Generator can produce typed clients from /v3/api-docs.

Is there RapidAPI marketplace integration?

Yes. ANKASecure© is available on RapidAPI, with usage tracked per RapidAPI subscriber.

Subscribe on RapidAPI → immediate API access, with no separate ANKASecure© sign-up.

What administrative tools exist for multi-tenant management?

The Key Management CLI keeps one configuration in ~/.ankasecure-km/ (or the directory named by ANKASECURE_KM_CONFIG).

How does automation administer the platform without a person's password?

As an administrative workload^*: a non-human principal of a tenant or of the platform that authenticates with a private key whose public half is registered on it, or with a token from a trusted issuer it is bound to — never a client secret — and receives five-minute DPoP-bound tokens for the Admin API (and, for a platform workload, the Audit API's platform integrity verification). The Key Management SDK (authenticateWorkload) and the Key Management CLI (init --workload-id) handle the proofs for a tenant workload. A workload holds only the scopes assigned to it, and never quorum approval, a key custody move, tenant identity-provider or account-recovery governance, tenant notification delivery or the cryptographic data plane (a tenant workload's keystore import excepted). The first platform workload is registered from the environment host with sudo envctl.sh <env> workload-bootstrap.

10. Policy engine

How does the multi-level policy system work?

Two-level policy hierarchy with simple fallback resolution:

Resolution: the tenant's own policy, when it has one, applies in full; otherwise the tenant inherits the deployment policy. A policy that cannot be resolved is never replaced by a permissive one: the governed operation is refused.

Validation at creation: a tenant policy must be a subset of the deployment policy (more restrictive, never less). This prevents security weakening — a tenant cannot enable algorithms that the deployment forbids.

Synchronization: a policy change reaches every service instance within seconds, without a restart.

What policy templates are available and how do I select one?

Templates are organized in three families:

Core: DEFAULT, POST_QUANTUM, CLASSICAL, NIST_APPROVED, HIGH_SECURITY, PQC_TRANSITION.

Regional: EU_COMPLIANT, CHINA_GMT_COMPLIANT, JAPAN_CRYPTREC, KOREA_KCMVP, GOST_COMPLIANT, US_NSA_CNSA, BSI_COMPLIANT, ANSSI_COMPLIANT, ETSI_QSC, GLOBAL_ISO_COMPLIANT, SAUDI_NCA_COMPLIANT, MALAYSIA_MYSEAL, IETF_RFC, FINANCE_COMPLIANT, NCSC_UK_PQC, CCN_CERT_ENS, ACN_ITALY_PQC.

Hybrid enforcement: BSI_HYBRID_ENFORCED, ANSSI_HYBRID_ENFORCED, ETSI_HYBRID_ENFORCED, EU_UNIFIED_HYBRID, NIST_HYBRID_OPTIONAL, ENISA_RISK_BASED.

Selection guidance:

Application: REST PUT /api/v3/admin/platform/deployment/policies/algorithm-availability or the Admin Console. A tenant administrator sets the tenant policy in the Admin Console; no workload is admitted to the tenant policy scopes.

For how a policy is applied and what it rejects, see the Policy Enforcement Guide.

How are policies enforced and what happens on violation?

Enforcement runs at every operation:

1. The tenant is taken from the tenantId claim of the validated JWT
2. The tenant's effective policy is resolved (its own, or the deployment policy it inherits)
3. The requested algorithm is validated against that policy: explicit algorithms, allowed families, required security levels, mandatory standards
4. On denial: HTTP 400 with an application/problem+json body (algorithm-not-admitted), and nothing is created

Example violations:

Enforcement runs on the server, in the Core API, for every operation, so a client cannot skip it. The way to change an outcome is to change the policy itself, through the Admin API, by a caller authorized to do so.

How fast do policy changes propagate across the platform?

Propagation is push-based:

1. The Admin API stores the policy change
2. It publishes the new policy to the platform's shared cache and notifies every Core API instance
3. Each instance discards its local copy for that tenant
4. The next request for that tenant is evaluated against the new policy

Sync modes:

Single tenant policy update: sub-second propagation. Full platform sync: tens of seconds depending on tenant count.

For what enforcement looks like from a caller's side, see the Policy Enforcement Guide.

Where to read next