DIGITAL SIGNATURES, DATA INTEGRITY AND REPLAY PROTECTION

RESPONSE SIGNATURE

SLASCONE API responses can be validated to ensure that they are authentic and have not been modified in transit. For this purpose, SLASCONE includes a digital signature in the response headers.

The response contains the header x-slascone-signature. This signature is generated from the content of the response body.

After receiving a response, the client should validate this signature to confirm that:

• the response came from SLASCONE
• the response body was not altered in transit

For implementation examples, see our GitHub code examples.

PUBLIC KEY

SLASCONE supports RSA-SHA256-based signature validation. The public key required for validation can be obtained from the Administration area of your SLASCONE environment.

Depending on your programming language or framework, the public key can be used either as a PEM file or as an XML string.

REPLAY PROTECTION

In addition to the response body signature, SLASCONE provides an optional mechanism to protect against replay attacks. This mechanism uses a nonce-based challenge-response flow.

Replay protection helps ensure that an attacker cannot capture a valid API response and successfully reuse it later.

How It Works

The nonce mechanism works as follows:

1. Client generates a nonce: Before making a request to the SLASCONE API, the client generates a unique random value, for example a GUID or cryptographically random bytes, and Base64-encodes it.
2. Client sends the X-Nonce header: The client includes this Base64-encoded value in the request header named X-Nonce.
3. Server signs the nonce: Upon receiving the request, the SLASCONE API extracts the nonce from the X-Nonce header, decodes it, and calculates a signature over the raw nonce bytes using the same signing mechanism that is used for the response body signature.
4. Server returns X-Nonce-Signature: The calculated signature is returned in the response header X-Nonce-Signature.
5. Client validates the signed nonce: The client verifies the X-Nonce-Signature against the nonce that was originally sent.

If the validation succeeds, the client can confirm that:

• the response came from the authentic SLASCONE server
• the response corresponds to the current request and was not replayed from an earlier interaction

Why It Protects Against Replay Attacks

A replay attack occurs when an attacker intercepts a valid API response and attempts to reuse it at a later time.

Without nonce protection, an attacker could potentially capture a valid response and try to replay it later, for example after a license has expired or been revoked.

With the X-Nonce mechanism:

• each request contains a unique, unpredictable nonce
• the server must sign this specific nonce to produce a valid X-Nonce-Signature
• captured responses cannot be reused for future requests with different nonces
• the client can detect whether the returned nonce signature belongs to the request it just sent

Implementation Example

Request:

GET /api/v2/isv/{isv_id}/provisioning/heartbeats
X-Nonce: rGxvYmFsLW5vbmNlLXZhbHVl

Response:

HTTP/1.1 200 OK
x-slascone-signature: <Base64-encoded signature of response body>
X-Nonce-Signature: <Base64-encoded signature of the decoded nonce bytes>
{ ... response body ... }

Signature Validation Modes

The nonce signature uses the same validation mode as the response body signature:

Best Practices

1. Always use unique nonces: Generate a new random value for each request, for example Guid.NewGuid().ToByteArray().
2. Store nonces temporarily: Keep the nonce in memory only for the duration of the request-response cycle.
3. Clean up old nonces: Remove stored nonces after validation or after a reasonable timeout.
4. Combine with body signature validation: For maximum security, validate both the x-slascone-signature header and the X-Nonce-Signature header.

SECURING YOUR SECRETS

Make sure to securely manage your secrets as described here.