This guide explains the silent duress mechanism in PulseProof Sentinel Protocol, abbreviated PPS.
Duress support is optional but one of the most sensitive features of PPS.
Duress occurs when a user is forced to authenticate or approve a transaction against their will.
Examples:
A duress mechanism allows the user to signal distress without alerting the attacker.
PPS uses a hidden duress key.
The device has at least two keys:
normal key
duress key
The server stores both public keys:
normal_pk
duress_pk
When the user authenticates normally:
Pulse signed by normal_sk
When the user authenticates under duress:
Pulse signed by duress_sk
The resulting duress Pulse is called a Honey-Pulse.
A Honey-Pulse is cryptographically valid.
The server recognizes it because the signing public key matches the registered duress public key.
The server MUST NOT reveal duress detection to the client.
Outwardly:
{
"status": "ok"
}
Internally:
{
"risk_level": "duress",
"account_mode": "restricted",
"alert": "silent"
}
Duress keys should be registered during device enrollment or later through a secure authenticated flow.
Registration payload may include:
pk = normal public key
duress_pk = duress public key
The registration message should be signed by both keys:
signature = normal_sk.sign(message)
duress_signature = duress_sk.sign(message)
This proves possession of both keys.
The PPS specification does not mandate a specific duress trigger.
Implementations may use:
User enters a special PIN.
Example:
Normal PIN: 2468
Duress PIN: 1357
User long-presses the approve button for several seconds.
User performs a hidden gesture in the UI.
User selects a predefined alternate word during confirmation.
User enables a hidden accessibility or advanced option.
Some systems use a special finger for duress.
This can be risky and should be designed carefully.
Duress UX must be:
Do not:
The attacker should see a normal authentication flow.
When a Honey-Pulse is detected, the server may:
The exact response depends on the application and risk model.
The duress response should be indistinguishable from normal success.
Match:
Avoid:
{
"status": "duress_detected"
}
Never do this.
Possible restricted modes:
User can view account but cannot transfer funds.
User can perform only small transactions.
Transactions are queued and reviewed.
Current session is limited, but future normal authentication may restore access.
No visible restriction, but activity is monitored closely.
Choose the mode based on user safety and business risk.
For transaction signing, duress handling is especially important.
Example:
Attacker forces user to approve withdrawal.
User signs with duress key.
Server returns success.
Server blocks withdrawal internally.
The attacker may believe the transaction succeeded.
This can protect assets while reducing immediate danger.
Duress triggers may be activated accidentally.
Design recovery carefully.
Possible false-positive handling:
Avoid locking users out permanently due to accidental duress activation.
Duress features may involve:
Do not automatically contact law enforcement unless legally appropriate and clearly disclosed.
Users should understand:
Test the following:
Threshold mode and duress can be combined carefully.
Possible models:
If any required device signs with a duress key, the whole approval may be treated as duress.
If a majority of signers use duress keys, treat as duress.
Only the primary device’s duress key triggers duress.
The chosen model must be explicit in the deployment policy.
Duress keys should be protected separately from normal keys.
Options:
If the normal master seed can derive the duress seed, an attacker who extracts the master seed may also obtain the duress key.
For stronger protection, use independent seeds.
Recommended incident playbook:
1. Honey-Pulse detected.
2. Do not alert attacker.
3. Restrict sensitive actions.
4. Create silent case.
5. Assign trained responder.
6. Monitor account activity.
7. Contact user through trusted channel if safe.
8. Escalate if necessary.
9. Preserve evidence.
10. Review after incident.
PPS duress support allows silent coercion signaling using a hidden key.
The most important rule:
Never reveal duress detection to the client.
Duress flows must be designed with user safety as the top priority.