Security Documentation
Understanding RSCP's threat model, cryptographic foundations, and security best practices.
Privacy by Protocol Design
RSCP's security guarantees are structural, not policy-based. The registry schema physically cannot store private data—it rejects undefined fields at the protocol level. This is fundamentally different from systems that rely on access controls or promises not to misuse data.
Threat Model
RSCP is designed to be secure against a variety of adversaries, each with different capabilities and goals.
Adversary Types
1. Malicious Issuer
An issuer who tries to create fake credentials or leak holder data.
- • Trust Anchor validates issuer identity before registration
- • Issuer DID is embedded in every credential
- • Verifiers check issuer against Trusted Issuer Registry
2. Compromised Registry
A registry operator that is hacked or acts maliciously.
- • Registry only stores public attributes by schema design
- • Private attributes (email, phone, scores) never transmitted
- • Even total database compromise reveals no private data
3. Curious Verifier
A verifier attempting to learn more than what was disclosed.
- • BBS+ derived proofs reveal only selected attributes
- • Predicate proofs hide actual values (prove score ≥ 80 without revealing 92)
- • Derived proofs are unlinkable across verifications
4. External Attacker
Network-level attacker attempting MITM, replay, or forgery.
- • All credentials are cryptographically signed
- • Presentations can be bound to specific verifiers
- • Short-lived presentations prevent replay attacks
- • TLS required for all network communication
5. Colluding Parties
Multiple parties working together to correlate or track holders.
- • Unlinkable presentations prevent cross-verification correlation
- • Holders can generate fresh presentations for each verification
- • Minimal disclosure reduces correlation surface
Security Properties
RSCP provides the following formally-defined security properties:
| Property | Definition | Mechanism |
|---|---|---|
| Unforgeability | Cannot create valid credentials without issuer private key | Ed25519 / BBS+ signatures |
| Integrity | Cannot modify credentials without detection | Cryptographic signatures |
| Holder Binding | Only the legitimate holder can create presentations | Holder key required for derivation |
| Selective Disclosure | Reveal only chosen attributes | BBS+ derived proofs |
| Predicate Privacy | Prove predicates without revealing values | Bulletproofs range proofs |
| Unlinkability | Cannot correlate multiple presentations | BBS+ proof randomization |
Attack Resistance Matrix
| Attack | Issuer | Registry | Verifier | Holder |
|---|---|---|---|---|
| Read private data | ||||
| Create fake credential | ||||
| Track holder | N/A | |||
| Replay presentation | N/A | N/A | N/A |
= Has access (by design) = Cannot perform (blocked by protocol)
Cryptographic Proofs
RSCP uses a combination of modern cryptographic primitives to achieve its security and privacy goals.
Ed25519 Signatures
Used for basic credential signing. Provides 128-bit security level with compact 64-byte signatures.
- Standard: RFC 8032
- Key size: 256-bit private, 256-bit public
- Signature size: 512 bits (64 bytes)
- Use case: Signing registry records, issuer authentication
BBS+ Signatures
Enables selective disclosure without revealing the full credential. Built on BLS12-381 pairing-friendly curve.
- Curve: BLS12-381
- Security: ~128-bit equivalent
- Feature: Derived proofs reveal only selected messages
- Use case: Selective disclosure presentations
How BBS+ Selective Disclosure Works
- Issuance: Issuer signs all credential attributes with BBS+ signature
- Derivation: Holder creates derived proof revealing only selected attributes
- Verification: Verifier checks proof validity without seeing hidden attributes
- Unlinkability: Each derived proof includes fresh randomness
Bulletproofs (Range Proofs)
Zero-knowledge proofs that a value lies within a range, without revealing the value itself.
- Range: 64-bit values
- Proof size: ~700 bytes (logarithmic in range size)
- Use case: Prove "testScore ≥ 80" without revealing actual score
SHA-256 Hashing
- Standard: FIPS 180-4
- Output: 256 bits (32 bytes)
- Use cases: Credential hashes, content-addressable identifiers, key derivation inputs
Key Management
Issuer Keys
Primary signing key for registry records
For selective disclosure-enabled credentials
Holder Keys
Holders use did:key identifiers backed by Ed25519 keys stored in the device's secure enclave (iOS Keychain, Android Keystore). These keys are used to prove ownership when creating presentations.
Best Practices
Security recommendations for each participant in the RSCP ecosystem.
For Issuers
Store Ed25519 and BBS+ private keys in FIPS 140-2 Level 3+ certified HSMs. Never store signing keys in application code, environment variables, or config files.
Rotate signing keys every 6-12 months. Publish new public keys to your DID document before retiring old keys. Keep old keys available for verification of existing credentials.
Log all credential issuance, revocation, and key operations. Include timestamps, operator identity, and credential IDs. Retain logs for regulatory compliance period.
Verify holder identity before credential issuance. Implement fraud detection for unusual issuance patterns. Set rate limits on credential creation.
For Wallet Applications
Store holder keys in iOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly or Android Keystore with setUserAuthenticationRequired(true).
Require Face ID, Touch ID, or fingerprint authentication before creating presentations or revealing credential details.
When creating presentations, default to minimal disclosure. Warn users when they choose to reveal more attributes than necessary.
Enable encrypted credential backup. Use key derivation from user password for backup encryption. Never back up holder private keys to cloud without encryption.
For Verifiers
Never trust credential data without cryptographic verification. Check signature validity before processing any attributes.
Always check the registry for revocation status, even for recently-seen credentials. Cache status for performance but use short TTL (5 minutes max).
Don't store verified credential data longer than necessary. Log verification events without storing full credential contents.
Always check that the issuer DID is in the Trusted Issuer Registry. Reject credentials from unknown or revoked issuers.
Common Vulnerabilities
| Vulnerability | Impact | Prevention |
|---|---|---|
| Key exposure | Credential forgery | Use HSM, never log keys |
| Replay attacks | Unauthorized verification | Use nonces, short expiry |
| Man-in-the-middle | Credential interception | TLS everywhere, pin certificates |
| Issuer impersonation | Fake credentials | Check Trusted Issuer Registry |
| Over-disclosure | Privacy breach | Minimal disclosure defaults |