pulseproof-sentinel

PPS Threat Model

This document describes the threat model for PulseProof Sentinel Protocol, abbreviated PPS.

PPS is experimental. This threat model is informative and should be expanded during implementation and deployment.

1. Purpose

The purpose of this threat model is to identify:

assets requiring protection
trust boundaries
attacker capabilities
likely threats
mitigations provided by PPS
residual risks

2. Assets

2.1. User Private Keys

The most important asset is the authenticator private key.

If an attacker obtains the private key, they may generate valid Pulses.

2.2. Duress Private Keys

Duress keys are also sensitive. If an attacker can force disclosure of the duress key, duress protection may fail.

2.3. Server Public-Key State

The server stores:

current public keys
duress public keys
counters
rotation sequence numbers
group threshold state

Integrity of this state is critical.

2.4. Nonces

Server nonces must be unpredictable and single-use.

Nonce reuse can enable replay attacks.

2.5. Transaction Data

For transaction signing, the integrity of transaction details is critical.

2.6. Audit Logs

Logs may contain:

authentication attempts
duress events
key rotations
threshold approvals
risk decisions

Logs must be protected.

2.7. User Safety

In duress scenarios, user safety may be more important than asset protection.

Silent alerts and restrictions must be designed carefully.

3. Trust Boundaries

3.1. Authenticator Device

The authenticator is trusted to:

protect private keys
verify user presence or biometric confirmation
display transaction details accurately
honor duress triggers
delete old ratchet keys when required

3.2. Relying Party Server

The server is trusted to:

verify Pulses correctly
protect public-key state
enforce rate limits
protect nonces
handle duress events safely
log securely

3.3. Network

The network is assumed to be hostile.

PPS assumes TLS or another secure transport for online flows.

Offline flows assume the Pulse may be intercepted.

3.4. User

The user is trusted to:

approve only intended operations
protect device access
use duress mechanisms when coerced
verify displayed transaction details

The user may be:

careless
phished
coerced
socially engineered

3.5. Secondary Devices

In threshold mode, secondary devices are trusted to:

authenticate the user
display transaction details
sign only intended payloads

4. Attacker Models

4.1. Remote Phisher

Capabilities:

fake login page
relay challenges
trick user into entering codes
trick user into approving prompts

PPS mitigations:

RP binding
nonce binding
context binding
transaction binding
full Pulse Token preferred over manual code
Trust Phrase comparison
AmountMark comparison

Residual risk:

user may approve a malicious request if UI is compromised

4.2. Man-in-the-Middle

Capabilities:

intercept traffic
modify requests
relay authentication

PPS mitigations:

TLS
nonce binding
RP binding
transaction hash binding
context binding
expiration

Residual risk:

MITM with valid TLS certificate may still relay if user approves

4.3. Server Breacher

Capabilities:

read server database
obtain public keys
obtain counters
obtain nonces
modify server state if write access exists

PPS mitigations:

no shared OTP secret stored
private keys not stored on server
public keys alone cannot generate Pulses

Residual risk:

attacker with write access may revoke keys, modify counters, or disrupt service

4.4. Malware on Authenticator

Capabilities:

request signatures
manipulate UI
capture user confirmation
extract keys if storage is weak

PPS mitigations:

secure hardware storage recommended
biometric confirmation recommended
transaction details displayed
threshold mode for high-value actions
duress signaling

Residual risk:

malware with full control can often defeat local protections

4.5. Physical Coercion

Capabilities:

force user to unlock device
force user to approve transaction
observe codes

PPS mitigations:

duress key
Honey-Pulse
fake success
silent alert
transaction limits

Residual risk:

attacker may force disclosure of all secrets
user safety may require compliance

4.6. Insider at Relying Party

Capabilities:

access logs
modify risk rules
ignore alerts
extract database

PPS mitigations:

audit logging
access control
separation of duties
encrypted logs
monitoring

Residual risk:

privileged insiders can abuse access

4.7. Relay Attacker

Capabilities:

relay BLE, NFC, QR, acoustic, or network messages
make devices believe they are close

PPS mitigations:

context binding
proximity hashes
short nonce lifetime
transaction binding
user confirmation

Residual risk:

proximity proofs are heuristic, not absolute

4.8. Future Quantum Attacker

Capabilities:

break Ed25519 with large-scale quantum computer

PPS mitigations:

algorithm agility
future post-quantum profiles
hybrid signature profiles

Residual risk:

current mandatory profile is not post-quantum

5. Threat Catalog

5.1. Shared Secret Theft

Traditional TOTP stores shared secrets on the server.

PPS mitigation:

Server stores only public keys.

Result:

database leakage does not allow Pulse generation

5.2. Phishing of OTP Code

TOTP codes can be phished and relayed.

PPS mitigation:

full Pulse Token is preferred
Pulse is bound to RP, nonce, context, and transaction
Trust Code fallback should be rate-limited

Residual risk:

manual Trust Code fallback is weaker

5.3. Replay Attack

An attacker captures a valid Pulse and replays it.

PPS mitigations:

nonce
epoch
expiration
monotonic counter
rotation sequence

Requirements:

nonces must be single-use
counters must be updated atomically

5.4. Downgrade Attack

An attacker tries to force weaker policy or Trust Code length.

PPS mitigations:

policy hash binding
server enforcement of minimum policy
reject unexpected policy hash

5.5. Transaction Tampering

An attacker changes amount or recipient.

PPS mitigations:

transaction hash in context
AmountMark in Trust Code
user-visible transaction confirmation

5.6. Key Extraction

An attacker extracts private key from authenticator.

PPS mitigations:

secure enclave
TPM
StrongBox
encrypted key storage
biometric unlock
threshold mode

Residual risk:

full device compromise may expose keys

5.7. Ratchet State Desynchronization

An attacker replays rotation certificates or causes key state drift.

PPS mitigations:

rotation sequence numbers
expiration
rate limiting
monitoring
re-registration fallback

Residual risk:

denial of service or state confusion

5.8. Duress Detection Leakage

If server response differs for duress, attacker may detect it.

PPS mitigations:

same HTTP status
same JSON shape
same latency
same UI flow
no explicit duress error

5.9. Threshold Collusion

Multiple devices collude or are compromised.

PPS mitigations:

higher threshold
device diversity
user presence per device
transaction limits
monitoring

Residual risk:

threshold cannot protect if enough devices are compromised

5.10. Privacy Correlation

A stable kid may allow correlation across services.

PPS mitigations:

use pairwise kid per RP
avoid personal data in identifiers
hash context fields
rotate identifiers when appropriate

5.11. Denial of Service

An attacker sends many invalid Pulses.

PPS mitigations:

rate limiting
nonce expiration
account lockout policies
IP throttling
anomaly detection

5.12. CBOR Parser Attacks

Malformed CBOR may exploit parser bugs.

PPS mitigations:

reject non-canonical CBOR
reject duplicate keys
reject indefinite length
reject unexpected types
use maintained CBOR libraries
fuzz parsers

6. STRIDE Summary

Threat Category	Example	PPS Mitigation
Spoofing	Fake authenticator	Ed25519 signature, registered public key
Tampering	Modify Pulse or transaction	signature over canonical CBOR, tx_hash binding
Repudiation	User denies action	signed Pulse, audit logs
Information Disclosure	Server secret leak	no shared secret stored
Denial of Service	Flood invalid Pulses	rate limiting, nonce expiration
Elevation of Privilege	Bypass policy	policy hash binding, server enforcement

7. Security Assumptions

PPS assumes:

Ed25519 is secure against classical attackers.
SHA-256 and HKDF-SHA256 are secure.
Random values are generated using a CSPRNG.
TLS protects online transport.
Authenticator private keys are protected by the device.
Server state integrity is protected.
Users verify displayed transaction details.
Duress mechanisms are configured safely.

8. Residual Risks

PPS does not eliminate:

user approval of malicious transactions
malware with full device control
coercion beyond duress protections
implementation bugs
weak key storage
poor operational security
future quantum attacks against Ed25519
relay attacks against proximity signals
insider abuse at relying party

9. Recommendations

For implementers

use well-reviewed cryptographic libraries
reject non-canonical CBOR
use constant-time comparison for Trust Codes
protect private keys with secure hardware
implement rate limiting
fuzz CBOR parsing
add audit logging

For deployers

prefer full Pulse Token over manual Trust Code
use nonce-bound online mode when possible
enforce strict rate limits for Trust Code fallback
monitor duress events carefully
use threshold mode for high-value actions
test incident-response playbooks
protect logs and public-key state

For users

verify transaction details before approval
use device biometrics or PIN
keep devices updated
use duress mechanisms only when safe
report suspicious authentication requests

10. Conclusion

PPS improves security compared with shared-secret OTP systems by removing shared secrets and adding strong binding mechanisms.

However, PPS is not a complete solution by itself.

Security depends on:

correct implementation
secure key storage
operational controls
user education
risk-based policy
incident response