Publish TKeeper Editions

Dockerfile

@@ -10,7 +10,6 @@ RUN dnf install -y \
       m4 \
       make \
       pkgconf-pkg-config \
-      wget \
       xz \
  && dnf clean all
 
@@ -38,8 +37,10 @@ RUN git clone https://github.com/bitcoin-core/secp256k1.git \
  && make -j"$(nproc)" \
  && make install
 
-RUN wget -O gmp.tar.xz https://ftp.gnu.org/gnu/gmp/gmp-6.3.0.tar.xz \
- && tar -xf gmp.tar.xz \
+COPY vendor/gmp/gmp-6.3.0.tar.xz vendor/gmp/SHA256SUMS ./
+
+RUN sha256sum --check --strict SHA256SUMS \
+ && tar -xf gmp-6.3.0.tar.xz \
  && cd gmp-6.3.0 \
  && ./configure --enable-shared --disable-static --enable-fat \
  && make -j"$(nproc)" \
@@ -49,6 +50,8 @@ FROM registry.access.redhat.com/ubi9/openjdk-25:1.24
 
 ARG TKEEPER_VERSION=dev
 ARG TKEEPER_JAR=build/docker/tkeeper.jar
+ARG TKEEPER_TARGET=all
+ARG TKEEPER_ECC=true
 
 LABEL maintainer="TKeeper Labs" \
       app.name="tkeeper" \
@@ -63,13 +66,16 @@ ENV JAVA_OPTS_APPEND="\
   -Dcom.sun.management.jmxremote=false \
   -Djdk.serialFilter=!* \
   -Djdk.tls.client.protocols=TLSv1.3,TLSv1.2 \
+  -Djava.library.path=/usr/local/lib:/usr/lib64:/lib64:/usr/lib:/lib \
+  -Dmsgpack.universal-buffer=true \
   -XX:+UseCompactObjectHeaders \
   --enable-native-access=ALL-UNNAMED"
 
 COPY --from=native-build /usr/local/lib/libgmp.so* /usr/local/lib/
 COPY --from=native-build /usr/local/lib/libsecp256k1.so* /usr/local/lib/
 COPY --from=native-build /usr/local/lib/libsodium.so* /usr/local/lib/
 COPY --chown=185:0 ${TKEEPER_JAR} /deployments/tkeeper.jar
+COPY --chown=185:0 tools/NativeJarSmoke.java /tmp/NativeJarSmoke.java
 
 RUN printf '%s\n' \
       'public class NativeSmoke {' \
@@ -83,7 +89,12 @@ RUN printf '%s\n' \
  && java \
       -Djava.library.path=/usr/local/lib \
       /tmp/NativeSmoke.java \
- && rm /tmp/NativeSmoke.java
+ && java \
+      --enable-native-access=ALL-UNNAMED \
+      -Djava.library.path=/usr/local/lib:/usr/lib64:/lib64:/usr/lib:/lib \
+      -cp /deployments/tkeeper.jar \
+      /tmp/NativeJarSmoke.java "${TKEEPER_TARGET}" "${TKEEPER_ECC}" \
+ && rm /tmp/NativeSmoke.java /tmp/NativeJarSmoke.java
 
 ENV JAVA_APP_JAR="/deployments/tkeeper.jar"
 

README.md

@@ -1,232 +1,62 @@
 ![TKeeper logo](assets/tk-bg.png)
 
-<div align="center">
-
 # TKeeper
 
-[TKeeper Labs](https://tkeeper.org) • [exploit.org](https://exploit.org) • [Documentation](docs/README.md) • [OpenAPI](openapi.yaml)
-
-</div>
-
-TKeeper is a governed cryptographic identity layer for machines, agents, services, and workflows.
-
-A TKeeper identity combines:
-
-- cryptographic key material, held locally or split across peers
-- an authority manifest that defines which typed actions the identity can authorize
-- controls for callers, policy, approvals, quorum, lifecycle, and audit
-
-While traditional access control decides whether a caller may reach an API, TKeeper also decides whether the selected identity may authorize the exact requested action.
-
-For typed authorities, the enforcement contract is simple: \
-**If TKeeper can't understand and approve the action, it won't produce signature.**
-
-## How it works
-
-```text
-Machine / Agent              TKeeper                             Backend
-───────────────              ───────                             ───────
-
-Requests an action    ────>   Understands the exact intent
-                              Enforces authority and policy
-                              Collects approval / quorum
-                              Produces signature           ────>  Verifies the signature
-                                                                  Executes the action
-```
-
-TKeeper produces a signature/transaction/certificate only after the request passes the identity's controls. The downstream system must enforce signature validation before executing the effect.
-
-## Use cases
-
-For each use case you can build TKeeper which its own feature modules.
-
-| Use case         | What the identity governs                                     |
-|------------------|---------------------------------------------------------------|
-| AI agents        | typed tool and production actions, spending, signed decisions |
-| Crypto assets    | exact EVM and Bitcoin transactions, treasury workflows        |
-| Certificates     | X.509 issuance and workload identity operations               |
-| Internal systems | typed commands, privileged automation, break-glass flows      |
-
-See [Use Cases](docs/use-cases/README.md).
-
-### Quick example
-
-An AI support agent can refund small orders automatically. Larger refunds require human approval.
-
-```yaml
-id: refund-order
-type: custom
-
-config:
-  fields:
-    orderId: { type: string }
-    amount: { type: bigint }
-    expiresAt: { type: time }
-
-policy:
-  fallback: DENY
-
-  approvers:
-    support-lead:
-      algorithm: ED25519
-      publicKey64: "..."
-
-  allow:
-    - id: automatic-refund
-      where:
-        - "bigint.lte(amount, '100')"
-        - "!time.after(time.now(), expiresAt)"
-
-    - id: reviewed-refund
-      where:
-        - "bigint.gt(amount, '100')"
-        - "bigint.lte(amount, '1000')"
-        - "!time.after(time.now(), expiresAt)"
-      approvals:
-        threshold: 1
-        approvers: [support-lead]
-```
-
-Now when AI agent asks TKeeper to sign a refund request
-- If refund amount is less or equal `100`, it will approve request and produce signature, that backend must verify before execution.
-- If refund amount is in `100.1000`, TKeeper will require [human approval](docs/security-model/four-eye-control.md) to produce proof.
-- If refund amount is more than `1000`, TKeeper will decline the request.
-
-```json
-{
-  "keyId": "support-agent",
-  "command": {
-    "type": "custom",
-    "authorityId": "refund-order",
-    "artifact": {
-      "scheme": "ECDSA",
-      "hash": "SHA256",
-      "typed": {
-        "orderId": "ord_123",
-        "amount": "<amount>",
-        "expiresAt": "2030-01-02T03:09:05Z"
-      }
-    }
-  }
-}
-```
-
-## Authorities
-
-Authorities define what a key identity may authorize.
-
-| Authority type         | Use                                                     |
-|------------------------|---------------------------------------------------------|
-| `arbitrary`            | raw signing; high-risk, no semantic intent in TKeeper   |
-| `custom`               | typed JSON commands, internal systems, AI-agent actions |
-| `evm.transaction`      | governed EVM transaction signing                        |
-| `bitcoin.transaction`  | governed Bitcoin transaction signing                    |
-| `x509.tbs-certificate` | governed certificate issuance                           |
+[Website](https://tkeeper.org) · [Documentation](docs/README.md) · [OpenAPI](openapi.yaml) · [Java SDK](sdk/README.md)
 
-Concrete authorities use digest-pinned authority documents that act as capability manifests. TKeeper materializes the command into an intent, evaluates policy, and signs only when the final decision is `ALLOW`.
-`custom` is available out of the box. Raw `arbitrary` signing is built in but disabled by default;
-enable `keeper.authority.arbitrary.enabled` only when raw signing is intentional. Other authority
-types can be included during the build.
+TKeeper provides cryptographic identities for AI agents, services, and other non-human actors. Each identity combines:
 
-See [Signing and Authorities](docs/signing-and-authorities/README.md).
+- a key, held by one node or split across a threshold quorum;
+- an authority manifest attached to that key, defining which actions it can authorize;
+- controls for callers, policy, approvals, audit, and key lifecycle.
 
-## Deployment modes
+As agents move from proposing actions to moving funds and changing production systems, applications need verifiable authorization for each action. TKeeper checks the identity's manifest and controls, then signs the approved action. The receiving system verifies that signature before executing it. Teams use this boundary to build and secure agent tools and payments, digital asset applications, PKI, and internal automation.
 
-TKeeper supports 2 deployment modes, one for low-risk and the other for mid-high risk organizations.
+## How an identity authorizes an action
 
-### Mono
-TKeeper is deployed as single instance. It is the simplest form designed for small orgs where no high-risk (e.g money transfers) actions are executed.
+1. A caller authenticates and requests a signature with a specific key.
+2. TKeeper checks the caller's permission and the key's authority. For a typed command, the authority interprets the action and its policy checks it.
+3. TKeeper collects required approvals and, in threshold mode, a signing quorum. An allowed command gets a signature.
+4. The receiving system verifies the signature or artifact, then executes the authorized action (for example, broadcasting the transaction).
 
-### Threshold
-TKeeper is deployed as `t` of `n` quorum, where `n` defines total number of TKeeper nodes, `t` defines **compromise tolerance** and `n-t` defines **fault tolerance**.
+`POST /v2/keeper/sign` returns a signature.
+`POST /v2/keeper/compose` runs the same checks and can return a signed transaction, payment credential or any other "composed" artifact. [Signing and Authorities](docs/signing-and-authorities/README.md) explains the request and policy model.
 
-Simply talking, if you deployed `2-of-3` configuration, it means that:
+Raw `arbitrary` signing has no intent policy and is disabled by default.
 
-- While **2** nodes are not compromised, attacker can't produce fake proof, steal key or tamper policies.
-- If **1** node is unavailable (e.g. network error), the system continues to work without interruptions.
+## What you can govern
 
-This mode is designed for high-risk organizations, as it allows to distribute risks inside/across organizations, prevents silent policy weakening, and even allows control to be shared externally (for example, between a platform and users of a crypto wallet).
+| Work                                                                | Guide                                                                                                                                                    |
+|---------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Agent tools over MCP; AP2 and Mastercard Verifiable Intent payments | [MCP action](docs/use-cases/for-ai.md#govern-an-mcp-action) · [AP2](docs/ai/agentic-payments/ap2.md) · [MC Intent](docs/ai/agentic-payments/mcintent.md) |
+| Bitcoin, EVM, Tron, XRP, and Solana transactions                    | [For Digital Assets](docs/use-cases/for-digital-assets.md) · [Chain authorities](docs/digital-assets/README.md)                                          |
+| X.509 certificate signing                                           | [For PKI](docs/use-cases/for-pki.md) · [X.509 example](docs/pki/x509.md#authority-example-workload-server-certificate)                                   |
+| Typed commands for internal systems                                 | [For Other Activities](docs/use-cases/for-other-activities.md) · [Custom authorities](docs/signing-and-authorities/arbitrary-and-typed.md)               |
 
-> 
-> TKeeper can be first configured in mono mode and then promoted to `t-of-n` quorum.
-> 
+## Multi-Party Computation and compromise resistance
 
-See [Quorum Modes](docs/security-model/quorum-modes.md).
+TKeeper supports `mono` and `threshold` operating modes. In `mono`, one host holds the full key material; compromising that host compromises the identity.
 
-## Documentation
+In `threshold` mode, TKeeper uses multi-party computation (MPC) for operations. Each peer holds one key share and checks the operation before contributing. A signature needs `t` accepted contributions from `n` peers. Normal threshold signing does not reconstruct the private key.
 
-- [Product Overview](docs/overview/README.md)
-- [Use Cases](docs/use-cases/README.md)
-- [Getting Started](docs/getting-started/README.md)
-- [Deployment](docs/deployment/README.md)
-- [Security Model](docs/security-model/README.md)
-- [Status and Limitations](docs/overview/status-and-limitations.md)
-- [Cryptographic Identities](docs/key-management/README.md)
-- [Signing and Authorities](docs/signing-and-authorities/README.md)
-- [Crypto Platforms](docs/crypto-platforms/README.md)
-- [API Reference](docs/api-reference/README.md)
-- [Operations](docs/operations/README.md)
+For a `2-of-3` identity, one compromised peer cannot sign alone or recover the key from its share. One unavailable peer leaves two that can still sign. The protection boundary ends at two compromised peers, and signing stops if fewer than two healthy peers can participate.
 
-## Build
+Place peers across separate hosts and failure domains to distribute compromise risk. Honest peers with matching authority and policy state reject actions that violate those rules, even if a minority peer is compromised. Keys created with distributed key generation never exist whole on one peer; imported or promoted keys may have existed whole earlier. See [Quorum Modes](docs/security-model/quorum-modes.md) and the [Threat Model](docs/security-model/threat-model.md).
 
-Cryptographic implementations are selected at build time.
+## Get started
 
-| Platform | Provides                                                                     |
-|----------|------------------------------------------------------------------------------|
-| `ecc`    | `SECP256K1`, `P256`, `ED25519`, ECDSA, FROST, BIP-340/Taproot, ECIES support |
-| `pqc`    | `MLDSA44`, `MLDSA65`, `MLDSA87`, threshold ML-DSA DKG and signing            |
+Follow [Local Single Node](docs/getting-started/local-single-node.md) to try TKeeper. A default production build requires Java 25:
 
-A deployable artifact must include at least one platform.
-
-Build all default production features and platforms:
-
-```bash
+```sh
 ./gradlew :build -Pkeeper.features=all -Pkeeper.platforms=all
 ```
 
-Build only what you need:
-
-```bash
-./gradlew :build -Pkeeper.features=authority-evm -Pkeeper.platforms=ecc
-```
-
-See [Build and Features](docs/deployment/build-and-features.md).
-
-## Security references
-
-**Security assurance:** 367 automated functional scenarios, including 90
-protocol and corruption failure-injection scenarios plus one 3-of-5 share-recovery scenario, run
-for every pull request and commit to `main`. See
-[Security Assurance](docs/security-model/security-assurance.md) for tested attack
-vectors and executable evidence.
-
-- [TKeeper Threat Model](docs/security-model/threat-model.md)
-- [Anvil](https://github.com/exploit-org/anvil) for protocol-level cryptographic components
-
-## API
-
-The HTTP contract is described by [openapi.yaml](openapi.yaml).
-
-Java integrations can use [`org.exploit:tkeeper-sdk:2.4.1`](sdk/README.md).
-
-## Verification
-
-Build a selected production artifact and run its root, SDK, feature, and platform unit tests:
-
-```bash
-./gradlew build -Pkeeper.features=all -Pkeeper.platforms=all
-```
-
-Run the complete release gate:
-
-```bash
-./gradlew releaseGate
-```
+`all` includes default production features. MCP, developer authentication, policy dry run, and recovery require explicit selectors. See [Build and Features](docs/deployment/build-and-features.md) before building a smaller artifact.
 
-`releaseGate` runs every module's unit tests, verifies artifact isolation, builds `exploit/tkeeper:dev` and `exploit/tkeeper:production-it`, and runs the functional integration suite. Performance benchmarks remain separate. Do not deploy either test image as production runtime.
+To package native libraries for one OS/CPU instead of all bundled variants, add `-Ptarget=linux-amd64` (or another [supported target](docs/deployment/build-and-features.md#select-a-native-oscpu-target)). The default `-Ptarget=all` keeps all bundled variants.
 
-See [integration-tests](integration-tests/README.md).
+Use the [Java SDK](sdk/README.md) or [OpenAPI](openapi.yaml) to integrate. For production boundaries, read the [Threat Model](docs/security-model/threat-model.md) and [Status and Limitations](docs/overview/status-and-limitations.md).
 
-## License
+Run the full release checks with `./gradlew releaseGate`. See [Integration Tests](integration-tests/README.md) for the Docker-backed suite.
 
 Apache License 2.0. See [LICENSE.md](LICENSE.md).

THREAT_MODEL.md

@@ -1,6 +1,6 @@
 # TKeeper Threat Model
 
-The maintained threat model lives in [docs/threat-model.md](docs/threat-model.md).
+The maintained threat model lives in [docs/security-model/threat-model.md](docs/security-model/threat-model.md).
 
 Protocol-level details for FROST, GG20, ECIES, ZK proofs, nonce handling, Paillier, and curve math live in the tss4j threat model: