Key Management SDK — Downloads

Package: AnkaSecure Key Management SDK
Artifact: co.ankatech:ankasecure-key-management-sdk:3.4.0 (Maven Central)
Version: 3.4.0
Java required: 17+
Distribution: signed, non-obfuscated JAR — a client library, not a deployable service

The Key Management SDK automates the key management of one tenant as an administrative workload: keys, key versions, rotation, destruction requests, the workload's own quorum requests, exchange contexts, exchanges, capability grants, constraint policies and internal cryptographic use cases. It performs no cryptographic operation. Encryption, signing and their inverses belong to the Runtime SDK.

Two ways to obtain it, and most integrations want the first:

1. A Maven or Gradle dependency resolved from Maven Central — Maven and Gradle coordinates. Nothing on this page needs to be downloaded by hand.
2. The JAR itself — the artifacts, for a build that cannot reach Maven Central: an air-gapped environment, a locked-down CI image, or a classpath assembled by hand. Central and this page serve the same bytes for a given version.

1. Artifacts

Every file below is published by the release that built it, at a path that names its version and is never replaced. The version in each filename is the release version — it is pinned automatically at publish time, so the names here always match the files actually served.

Aggregate checksum file covering both JARs in one document:

• sha256sums

The Javadoc JAR is the API reference for offline use. Attach it as the sources/javadoc artifact in your IDE to get inline documentation on every AnkaSecureKeyManagementSdk method.

2. Verifying what you downloaded

Verify before you put the JAR on a classpath. The library signs in with an administrative workload's key at runtime.

if head -c2 ankasecure-key-management-sdk-3.4.0.jar | grep -q PK; then
    echo "looks like a JAR"
else
    echo "not a JAR - you were redirected, not signed in"
    head -c200 ankasecure-key-management-sdk-3.4.0.jar
fi

Linux / macOS

Run this in the directory where the browser saved the JAR and its .sha256.

# the .sha256 file holds the bare digest, so compare it directly.
# stock macOS has no sha256sum: use `shasum -a 256` there.
actual=$(sha256sum ankasecure-key-management-sdk-3.4.0.jar | cut -d' ' -f1)
expected=$(tr -d '[:space:]' < ankasecure-key-management-sdk-3.4.0.jar.sha256)
if [ "$actual" = "$expected" ]; then echo OK; else echo MISMATCH; fi

Windows (PowerShell)

$expected = (Get-Content ankasecure-key-management-sdk-3.4.0.jar.sha256).Trim()
$actual   = (Get-FileHash ankasecure-key-management-sdk-3.4.0.jar -Algorithm SHA256).Hash.ToLower()
if ($actual -eq $expected) { "OK" } else { "MISMATCH" }

To verify both JARs at once against the aggregate instead, save sha256sums beside them and run:

sha256sum -c --ignore-missing sha256sums     # macOS: shasum -a 256 -c --ignore-missing sha256sums

Expect ankasecure-key-management-sdk-3.4.0.jar: OK for each JAR and exit 0.

3. Maven and Gradle coordinates

The recommended route. The Key Management SDK is published to Maven Central, so a build that can reach Central needs no repository declaration and none of the artifacts.

Maven

<dependency>
    <groupId>co.ankatech</groupId>
    <artifactId>ankasecure-key-management-sdk</artifactId>
    <version>3.4.0</version>
</dependency>

Gradle

implementation 'co.ankatech:ankasecure-key-management-sdk:3.4.0'

Every transitive dependency resolves from Central too. Each published version carries the JAR, its sources and Javadoc JARs and its POM, each with an .asc signature made with the AnkaTech release key, whose public key is published on keys.openpgp.org and keyserver.ubuntu.com. A version on Central is immutable: it is never replaced or withdrawn.

Local JAR, when the coordinate cannot be resolved — download from Artifacts, then:

<dependency>
    <groupId>co.ankatech</groupId>
    <artifactId>ankasecure-key-management-sdk</artifactId>
    <version>3.4.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/libs/ankasecure-key-management-sdk-3.4.0.jar</systemPath>
</dependency>

implementation files('libs/ankasecure-key-management-sdk-3.4.0.jar')

4. Runtime requirements

No JAR bundles a Java runtime — unlike the Key Management CLI installers, which ship one. The SDK is a library and uses the JVM your application already runs on.

5. Past releases

Every published version keeps its own permanent path, /downloads/key-management-sdk/<X.Y.Z>/, and its files are never replaced or removed. The links on this page name the release this documentation version was built from; the version selector at the top of the page opens another version's page.

• Every published version of the Key Management SDK — newest first, each version with its files and their SHA-256 checksums.
• /downloads/key-management-sdk/latest/<file> redirects to <file> in the greatest published version, and /downloads/key-management-sdk/latest/ to that version's entry in the listing. File names carry their version, so a script that must always fetch the newest release reads the component's latest from the releases index below and then fetches the versioned path; a reproducible build pins a version instead.
• /downloads/releases.v1.json is the machine-readable index of every version of every component this site publishes (schemaVersion 1; per file its name, size and SHA-256).

Releases before the Key Management SDK were published as the Admin SDK (co.ankatech:ankasecure-admin-sdk, /downloads/admin-sdk/). Those downloads stay where they are; no later release is published under that name.

6. Next steps

1. Verify the download against its SHA-256 (see verifying what you downloaded).
2. Add the dependency (see Maven and Gradle coordinates).
3. Read Prerequisites — the workload, its key and its scopes.
4. Start with Quick Start, then the Usage Guide.
5. Read Key Destruction before you request the destruction of a key.

Compatibility with newer servers

The SDK's generated models ignore a response member they do not declare, so a server of a later release that adds a member to a response does not break a client built on an earlier SDK. A required member that is missing, or a member of the wrong type, is still refused. The ignored member is not kept: a model read from a response and sent back in a request carries only the members the SDK declares.

A generated enum reads a value it does not declare as UNKNOWN_DEFAULT_OPEN_API instead of failing the response, and the server's value stays readable through the member's get<Member>AsString() accessor. Code that switches over a generated enum handles that constant explicitly.

One exception remains. A value that can take one of several shapes with no discriminator member is told apart by each shape's exact member set, so a member the SDK does not declare inside such a value still matches no shape and the response is refused. The key rotation schedule (KeyRotationScheduleView) carries such a value.

Version: 3.4.0
Java required: 17+
Server compatibility: AnkaSecure Admin API 3.4.0+ and Auth API 3.4.0+ — a floor, not this release's version. It is deliberately not pinned by the release: it records the oldest server this SDK can talk to, and that changes only when a breaking contract change forces it.

© 2026 ANKATech Solutions Inc. All rights reserved.