Protocol: PulseProof Sentinel Protocol
Abbreviation: PPS
Protocol Version: 1
Status: Experimental
Internet-Draft: draft-hezami-pulseproof-sentinel
Specification: SPEC.md
PulseProof Sentinel Protocol, abbreviated PPS, is an experimental authentication protocol based on time-bound asymmetric proofs.
Traditional TOTP uses a shared secret:
TOTP = HMAC(shared_secret, time)
PPS replaces the shared secret with a private key held by the user’s device:
Pulse = Sign(private_key, time + rp + nonce + counter + context + policy)
The server verifies the proof using only the corresponding public key.
A PPS authentication artifact is called a Pulse.
PPS is designed to complement, not replace, WebAuthn/FIDO2.
WebAuthn is excellent for browser-based, origin-bound, phishing-resistant authentication. However, many real-world systems still need authentication flows that WebAuthn does not fully cover:
PPS targets these operational gaps.
In short:
Use WebAuthn when a full browser/platform passkey ceremony is available.
Use PPS when you need an OTP-like, offline, terminal-friendly, transaction-aware,
or duress-aware asymmetric proof.
PPS changes the authentication model.
Client and server share a secret.
Client proves knowledge of the secret by generating a short code.
Server verifies the code using the same secret.
Client holds a private key.
Server holds only the public key.
Client proves possession of the private key by signing a time-bound payload.
Server verifies the signature using the public key.
This removes the shared-secret exposure problem from the server side.
A Pulse is a signed statement generated by an authenticator device.
It proves possession of a private key bound to:
A Pulse Token is the serialized form of a Pulse.
The canonical encoding is deterministic CBOR.
The textual encoding is base64url without padding.
A Trust Code is a short human-verifiable numeric value derived from the cryptographic proof.
Example:
493718
The Trust Code is not the primary authentication secret. The full Pulse Token is preferred.
Manual Trust Code entry should be protected by strict rate limiting.
A Trust Phrase is an optional human-friendly phrase derived from the proof.
Example:
river bronze lantern
It can be used for visual confirmation.
For transaction signing, PPS can embed a two-digit amount checksum into the Trust Code.
Example:
Amount: 2,500,067 IRR
Trust Code: 49371867
The last two digits, 67, are derived from the transaction amount.
This helps users detect transaction tampering.
PPS supports optional forward-secure key rotation.
Each Pulse can authorize a next public key:
current key signs Pulse + next_pk
After successful verification, the server updates its stored public key.
The authenticator deletes the old private key when possible.
A Rotation Certificate is a signed statement authorizing transition from one public key to another.
Rotation certificates allow offline or asynchronous key rotation catch-up.
PPS supports an optional hidden duress key.
If the user authenticates under coercion, the authenticator signs with the duress key.
The server recognizes the duress public key but returns an outwardly normal response.
This is called a Honey-Pulse.
PPS supports optional offline multi-device approval.
Example:
phone signs
watch signs
server requires both signatures
This is useful for high-value transactions.
PPS version 1 uses n-of-m Ed25519 multisignature.
Future versions may define true threshold signatures such as FROST.
A Pulse can be bound to environmental or session context:
A Pulse can be bound to a server-issued policy object.
Example policy requirements:
PPS uses several replay-protection mechanisms:
epoch = time window
counter = monotonic device or group counter
nonce = server-issued one-time value
exp = expiration epoch
Together they provide strong replay protection when used correctly.
PPS has three main actors:
User
Authenticator Device
Relying Party Server
The authenticator may be:
The relying party is the service verifying authentication.
1. User authenticates to the RP using an existing method.
2. RP issues a registration nonce.
3. Authenticator generates a key pair.
4. Authenticator signs a registration payload.
5. Optionally, authenticator registers a duress public key.
6. RP verifies signatures.
7. RP stores only public keys.
The RP never stores a private key or shared OTP secret.
Initial server state:
current_pk = registered public key
key_seq = 0
last_ctr = 0
If duress is registered:
duress_pk = registered duress public key
duress_key_seq = 0
duress_last_ctr = 0
1. RP creates a challenge.
- nonce
- rp_id
- optional transaction hash
- optional policy object
2. Authenticator receives the challenge.
- QR code
- deep link
- SDK
- manual context
3. Authenticator signs a Pulse.
4. Authenticator optionally displays:
- Trust Code
- Trust Phrase
- AmountMark
5. RP verifies:
- signature
- rp binding
- nonce
- epoch
- expiration
- counter
- policy
- context
- amount mark
- rotation state
6. Authentication or transaction approval succeeds.
Online nonce-bound mode is the recommended default.
PPS can operate without a live network round-trip.
In offline mode, the nonce may be omitted.
Offline security relies more heavily on:
Online nonce-bound mode is preferred when possible.
Offline mode is useful for:
PPS is suitable for transaction approval flows.
The RP creates a transaction hash:
tx_hash = SHA256(canonical_transaction_object)
The transaction hash is included in the context object.
The authenticator displays transaction details and signs only after user confirmation.
Example:
Withdrawal request
Amount: 2,500,067 IRR
To: IR820540102680020817909002
Service: example.com
Trust Code: 49371867
[Reject] [Approve Withdrawal]
The last two digits of the Trust Code match the last two digits of the amount.
If the user is forced to authenticate, the authenticator can use a hidden duress key.
Normal authentication:
Pulse signed by normal_sk
Duress authentication:
Pulse signed by duress_sk
The server detects the duress public key and may:
The outward response should be indistinguishable from normal success.
See duress-guide.md.
Threshold mode allows multiple devices to approve the same Pulse.
1. Initiating device creates Pulse payload.
2. Payload is shared with other devices.
3. Each device verifies transaction details.
4. Each device asks for user confirmation.
5. Each device signs the same payload.
6. Signatures are collected.
7. Final envelope contains all signatures.
8. Server verifies required signatures.
Example:
2-of-3:
phone
watch
laptop
Any two devices can approve.
See threshold-guide.md.
PPS allows the RP to define dynamic security requirements.
Example policy:
{
"min_trust_digits": 8,
"require_biometric": true,
"require_secure_enclave": true,
"threshold": 2,
"max_amount_minor": 10000000,
"require_proximity": true,
"require_amount_mark": true
}
The policy is hashed and bound to the Pulse.
Example context:
{
"session_id": "base64url",
"tx_hash": "base64url",
"ble_hash": "base64url"
}
The context is hashed and bound to the Pulse.
See policy-guide.md.
The mandatory profile is:
PPS-ED25519-CBOR30
It uses:
| Component | Value |
|---|---|
| Signature algorithm | Ed25519 |
| Hash algorithm | SHA-256 |
| KDF | HKDF-SHA256 |
| Canonical encoding | Deterministic CBOR |
| Text encoding | base64url without padding |
| Default epoch length | 30 seconds |
Optional post-quantum and hybrid profiles may be defined in future revisions.
PPS can replace TOTP in systems that need an OTP-like artifact but want stronger cryptographic guarantees.
PPS can be used by constrained terminals, POS devices, and field hardware.
PPS can sign high-value transactions with visible amount confirmation.
Threshold mode and AmountMark are useful for withdrawals and transfers.
Threshold mode can require multiple administrators or devices.
PPS can support silent coercion signaling.
PPS can provide asymmetric proof for devices with limited UI.
PPS can be used alongside WebAuthn, OAuth, or risk-based authentication.
PPS does not attempt to be:
PPS may be combined with such systems.
PPS builds on many existing ideas and standards, including:
PPS does not claim that these individual mechanisms are new.
Its contribution is an interoperable protocol profile combining them into a compact, technology-agnostic wire format for offline, OTP-like, transaction-signing, duress-aware, and threshold authentication flows.
PPS is designed to be implementable in common technologies:
The specification does not depend on a specific programming language, operating system, or transport.
PPS is experimental.
It has not been independently audited.
It should not be used in production without:
See threat-model.md.
Recommended reading: