The problem with comparing request signing to secret retrieval

If you are comparing AWS SigV4 vs SikkerKey, the important question is not whether both systems can sign HTTP requests. They can.

The important question is what kind of credential the workload must hold when it asks for a secret.

That is where the difference is sharp:

AWS SigV4 is symmetric signing. It signs requests with HMAC-SHA256 using signing keys derived from AWS secret access key material.
SikkerKey is asymmetric signing. Each machine signs secret-read requests with its own Ed25519 private key, and SikkerKey verifies those requests with the machine's public key.

For secret retrieval, asymmetric machine identity is the stronger model. The server can verify a machine without holding a reusable machine signing secret. A public key can verify a signature, but it cannot create one. That changes what an attacker can steal, what operators need to rotate, and how precisely access can be revoked.

SigV4 is AWS API authentication, not a machine-first secrets model

AWS SigV4 was built to authenticate AWS API requests. The client creates a canonical request, derives a signing key from AWS credentials, signs the request, and sends the signature. AWS reproduces the signing process and checks whether the result matches.

That is symmetric signing. The security boundary is the AWS credential material used to derive signatures. Temporary STS credentials can shorten the lifetime, and IAM can narrow what the credential can do, but the workload still needs credentials that can produce valid AWS API signatures while they are alive.

That is the part teams should care about when they are choosing a secrets manager. If a runtime has to hold a credential that can sign new requests, then that credential becomes a target. Short expiry helps. IAM scoping helps. Rotation helps. But the runtime still has a usable signing credential.

SikkerKey removes that shape from the application read path. It does not give applications a shared SikkerKey API key. It does not hand back a bearer token for secret reads. It gives each machine an asymmetric identity and verifies that identity on every request.

SikkerKey starts with the machine, not a shared credential

When a machine is bootstrapped into SikkerKey, it gets an Ed25519 keypair. The private key stays on the machine. SikkerKey stores the public key.

From then on, every SDK and CLI read is signed by that machine:

method:path:timestamp:nonce:bodyHash

The request carries:

X-Machine-Id
X-Timestamp
X-Nonce
X-Signature

SikkerKey rebuilds the signed payload from the actual request, verifies the Ed25519 signature with the stored public key, checks the timestamp, and records the nonce. A captured request cannot be replayed because the nonce is one-time per machine and the timestamp must be fresh.

The key point is simple: SikkerKey can verify a machine without storing a secret that can impersonate that machine.

That is the difference between symmetric and asymmetric retrieval. In SikkerKey, the server-side authentication record is not a signing credential. It is a public key.

What an attacker gets is different

This is the cleanest way to compare the models.

With symmetric request signing, a stolen valid credential is useful because it can create new signatures. The attacker still has to stay within policy and lifetime, but the credential itself is active signing material.

With SikkerKey's asymmetric machine identity, a stolen public key is not useful. It cannot sign a request. A captured old request is not useful either because the nonce has already been recorded and the timestamp window closes quickly. The attacker needs the private key from the machine that is actually allowed to read the secret.

That gives SikkerKey a better failure model for secrets:

No SikkerKey bearer token is sitting in application config.
No shared SikkerKey API key is copied across CI, servers, and serverless platforms.
No server-side machine signing secret exists for an attacker to steal from SikkerKey and reuse.
Past requests are bound to method, path, body hash, timestamp, and nonce.
Disabling or revoking a machine changes the next read decision immediately.

This is why asymmetric signing matters. It is not an implementation detail. It changes the credential an attacker is trying to steal.

Request authentication is not enough for secrets

A signed request only proves that some credential signed a request. Secret retrieval needs a stricter decision: should this exact machine receive this exact secret right now?

SikkerKey answers that at the read path.

Before returning a secret, SikkerKey checks:

the Ed25519 signature is valid
the timestamp is fresh
the nonce has not been used by this machine
the machine is approved
the machine is enabled
the machine has not expired
the source IP is allowed by vault-level controls
temporary-machine guardrails pass when configured
the vault owner account allows runtime access
the project is not frozen
the machine belongs to the project
the machine has an explicit grant for the requested secret
the secret belongs to the machine's vault
any bound access policy allows the read

Only after those checks does SikkerKey unwrap the project key, decrypt the secret's data key, decrypt the value, return it, and record the audit event.

That is the vendor point: SikkerKey is not selling a generic signing algorithm. SikkerKey is selling a better secret retrieval boundary.

Machine-to-secret grants are easier to reason about

IAM-style policy systems can express a lot, but they also spread the answer across several places. A team often has to inspect identity policies, resource policies, role assumptions, session context, tags, KMS permissions, and environment-specific credential delivery before it can answer a basic question: can this workload read this secret?

SikkerKey makes that question concrete:

A project holds secrets.
A machine is attached to a project.
The machine still needs an explicit grant for each secret.
SDKs and the CLI reflect live server-side grants.

Project membership alone is not enough. A stale grant is not enough if the machine is no longer in the project. A machine in another vault cannot cross over and read the secret.

This is a better operational model for secrets because the unit of access is the thing doing the reading: the machine.

Policies are enforced before decryption

SikkerKey's access policies sit directly on the secret read path. They are evaluated before the value is decrypted.

A secret can require:

time windows
IP or CIDR allowlists
per-minute or per-day read caps
co-signed access by another machine
expiration by time
destruction after a maximum number of reads
rotation after a number of reads

Application code does not need to implement those controls. The SDK still calls getSecret, getField, or export. SikkerKey enforces the policy centrally, records blocks, updates counters, and triggers post-read behavior when configured.

That matters because secrets controls should not be scattered across every application. They should be enforced where the secret is retrieved.

Canaries turn secret reads into incident signals

SikkerKey can also plant canary secrets. A canary secret is a tripwire: if an unexpected machine reads it, SikkerKey can freeze the project and optionally related projects.

The read can still return so the response stays stealthy, but subsequent reads against the frozen project are blocked. Operators get the audit trail around the originating read and the freeze.

This is another reason SikkerKey is stronger than a request-signing comparison suggests. Secret retrieval is not only about allowing good requests. It is also about detecting suspicious reads and changing the system state when a secret looks compromised.

AWS SigV4 vs SikkerKey

Area	AWS SigV4	SikkerKey
Core model	AWS API request signing	Secret retrieval with machine identity
Signing type	Symmetric	Asymmetric
Algorithm	HMAC-SHA256	Ed25519
Runtime credential	AWS access key or STS credential material	Machine private key
Server-side verifier	Credential-derived signing calculation	Stored machine public key
Server-side impersonation risk	Verification depends on AWS credential material and policy context	Stored machine public keys cannot impersonate machines
Replay defense	Timestamp window	Timestamp window plus persisted one-time nonce per machine
Access unit	AWS principal and IAM policy	Machine, project membership, and explicit secret grant
Secret policy layer	Built through AWS/IAM/KMS configuration	Built into the SikkerKey read path
Incident controls	External service design required	Canary secrets and project freeze built in
Cloud fit	AWS-native	Cloud-independent and multi-platform

SigV4 is the wrong center of gravity for teams that want cloud-independent secret retrieval. It is AWS API authentication. SikkerKey is machine identity for secrets.

Why SikkerKey is the stronger AWS Secrets Manager alternative

SikkerKey is stronger because it changes the runtime credential model.

Instead of giving an application a symmetric credential that can sign new requests, SikkerKey gives each machine an asymmetric identity. The private key stays on the machine. The server stores a public key. Every read is signed, replay-protected, authorized against live grants, checked against policies, decrypted only after authorization, and audited.

That gives teams a simpler and tighter operating model:

The application does not carry a shared SikkerKey token.
Operators grant secrets to machines, not vague runtime blobs.
Access changes take effect on the next read.
Policies and canaries run centrally on the retrieval path.
The same model works across AWS, other clouds, CI, containers, servers, and serverless jobs.

For teams searching for AWS Secrets Manager alternative, SigV4 vs asymmetric signing, machine identity for secrets, or secure secret retrieval, this is the practical takeaway: AWS SigV4 uses symmetric credentials to sign AWS API calls. SikkerKey uses asymmetric machine identity to decide whether a machine can receive a secret.

That is the stronger boundary.

FAQ

Is AWS SigV4 symmetric or asymmetric? AWS SigV4 is symmetric signing. It uses HMAC-SHA256 with signing keys derived from AWS secret access key material, date, region, and service. AWS SigV4a is a separate asymmetric variant for multi-region request signing.

Is SikkerKey symmetric or asymmetric? SikkerKey uses asymmetric signing. Each machine signs secret-read requests with an Ed25519 private key, and SikkerKey verifies those requests with the machine's stored public key.

Why is asymmetric signing better for secret retrieval? Because the verifier does not need a signing secret. SikkerKey can store public keys that verify machines without storing machine credentials that can impersonate them.

Does SikkerKey use bearer tokens for application reads? No. Runtime reads are signed with the machine's Ed25519 private key. The private key stays on the machine.

What prevents replay attacks in SikkerKey? Every signed request includes a timestamp and a random nonce. The timestamp must be fresh, and the nonce is stored after signature verification so it cannot be reused by the same machine.

Is SikkerKey only for AWS? No. SikkerKey's machine identity model is cloud-independent. It works across AWS, other clouds, CI, containers, servers, serverless platforms, and hybrid environments.