Thư viện · Nền tảng
Signing requests and responses: what each signature proves
The device's signature proves a request came from that machine unchanged. The app's signature proves the answer came from the real server. Missing either one leaves a door open.
Two different questions
- Did this request come from that device? The device signs the method, path, body hash, time and nonce with its private key.
- Did this answer come from the server? The server signs the status, the request's nonce, the time and the body hash with the app key.
Why answers must be signed too
If only requests are signed, a fake server that always says "license valid" is enough. Software must refuse any answer without a valid signature, error answers included.
Bind the answer to the request
The response signature covers the request nonce, so an old "success" cannot be pasted onto a new request.
Rotation
App signing keys need replacing over time. Each answer carries a kid so the SDK picks the right key during the handover.
With ClavisAUH
CLV1 signs both ways by default, and Response Signing is part of Standard Protection. In Advanced Protection, turn on Signing Key Rotation to get a reminder when a key change is due.