PhantomKey Security Design Rules

Codified Security Principles for All Products

Organization: PhantomKey Technologies
Author: Stan Pressman
Date: 2026-02-28
Status: Living Document - Updated as rules evolve
Applies to: DaiVernon Teams (DV-T), DaiVernon Enterprise (DV-E), Schrödinger, all future products

Purpose

This document codifies the security design rules that govern all PhantomKey products. These are NOT guidelines or suggestions - they are MANDATORY requirements that must be followed in every feature, every component, every line of code.

When in doubt, refer to this document. If a feature violates these rules, it does not ship.

Core Philosophy: Zero-Persistence Architecture

Principle: Sensitive data exists only in memory during active use, never persisted to disk in any form.

Rationale: The only truly secure data is data that doesn't exist. If it's not on disk, it can't be stolen from disk.

Category 1: Password & Passphrase Storage

Rule 1.1: NEVER Store Passwords in Plaintext

PROHIBITED:

• Writing passwords to disk (files, databases, logs)
• Storing passwords in environment variables
• Embedding passwords in code or configuration files
• Transmitting passwords in URL parameters
• Logging passwords to console (even debug mode)

EXCEPTION: None. No exceptions to this rule.

Enforcement: Code review must verify zero plaintext password storage.

Rule 1.2: NEVER Store Password Hashes on Disk

PROHIBITED:

• Saving password hashes to files for "quick unlock"
• Caching password hashes in memory beyond session lifetime
• Persisting hashes to optimize performance

RATIONALE: Even hashes can be cracked (rainbow tables, GPU attacks). Zero-persistence means zero hashes.

ALLOWED:

• Hashes in memory during active session only
• Hashes immediately cleared on lock/logout

ENFORCEMENT: Memory inspection must show no password hashes after logout.

Rule 1.3: NEVER Store Encryption Keys on Disk

PROHIBITED:

• Writing encryption keys to files (even encrypted)
• Storing keys in OS keychain/credential manager
• Persisting keys across sessions

ALLOWED:

• Keys derived from passphrases in memory (during session)
• Keys immediately cleared from memory on logout
• Keys in secure enclaves (TPM, Secure Enclave) if hardware-backed AND session-scoped

EXCEPTION: Master keys for emergency break-glass access (stored in HSM with multi-signature, documented in compliance docs).

ENFORCEMENT: File system scan must show zero key files after logout.

Rule 1.4: NEVER Implement Password Hints

PROHIBITED:

• "Hint" fields in password creation forms
• "Security questions" for password recovery
• "Forgot password" flows that weaken security

RATIONALE: NIST SP 800-63B explicitly recommends AGAINST password hints and security questions. They reduce entropy and enable social engineering.

ALLOWED:

• Clear documentation that forgotten passphrases = permanent data loss
• User education during onboarding: "Write down your passphrase and store it securely"

REFERENCE: NIST SP 800-63B Section 5.1.1.2: "Verifiers SHOULD NOT permit the subscriber to store a 'hint' that is accessible to an unauthenticated claimant."

ENFORCEMENT: Code review must reject any "hint" or "security question" fields.

Rule 1.5: NEVER Implement "Reset Password" via Email

PROHIBITED:

• Email-based password reset links
• SMS-based password reset codes
• Any mechanism that allows password recovery without original passphrase

RATIONALE: Email accounts are frequently compromised. Email-based reset = backdoor for attackers.

ALLOWED:

• Emergency access via master key (enterprise only, multi-signature required)
• Account recovery via hardware security key (if implemented)

ENFORCEMENT: No password reset API endpoints. Period.

Category 2: Data Persistence & Storage

Rule 2.1: Encrypted Data Only on Disk

REQUIRED:

• All sensitive data encrypted before writing to disk
• Encryption keys never stored with encrypted data
• Encryption performed in memory, encrypted output written to disk

PROHIBITED:

• Temporary files with plaintext sensitive data
• Swap files containing decrypted secrets
• Memory dumps with decrypted data

ENFORCEMENT: File system audit must show only encrypted blobs, no plaintext.

Rule 2.2: Zero Temporary Files

PROHIBITED:

• Creating temp files with passwords/keys (even if deleted after)
• Relying on OS to clean up temp files
• Writing sensitive data to /tmp, %TEMP%, or similar

ALLOWED:

• In-memory temporary storage (RAM only)
• Secure deletion if temp files absolutely necessary (overwrite 7 times before delete)

ENFORCEMENT: Code review must verify no temp file creation with sensitive data.

Rule 2.3: Zero Logging of Sensitive Data

PROHIBITED:

• Logging passwords, passphrases, keys, or decrypted data
• Debug logs containing sensitive information
• Error messages that leak secrets

ALLOWED:

• Logging encrypted blobs (not sensitive)
• Logging metadata (user ID, timestamp, action) without sensitive payload
• Logging "Password decryption failed" but NOT the attempted password

EXAMPLE VIOLATION:

// WRONG:
console.log('Unlocking vault with passphrase:', userPassphrase);

// RIGHT:
console.log('Unlocking vault...');

ENFORCEMENT: Grep codebase for log statements, verify no sensitive data logged.

Rule 2.4: Secure Memory Clearing

REQUIRED:

• Overwrite sensitive data in memory before releasing
• Use secure memory clearing functions (not just delete or null)
• Clear memory on logout, lock, error, or crash

EXAMPLE:

// WRONG:
let password = 'secret123';
password = null; // Still in memory as garbage

// RIGHT:
let password = 'secret123';
secureMemoryClear(password); // Overwrite with zeros before release
password = null;

ENFORCEMENT: Memory profiler must show no secrets in memory after logout.

Category 3: Transmission & Network Security

Rule 3.1: HTTPS/TLS for All Network Traffic

REQUIRED:

• All API calls over HTTPS (TLS 1.2 minimum, TLS 1.3 preferred)
• Certificate pinning for critical endpoints (optional but recommended)
• No fallback to HTTP under any circumstances

PROHIBITED:

• HTTP for any sensitive data transmission
• Self-signed certificates in production
• Disabling TLS verification

ENFORCEMENT: Network inspection must show zero HTTP traffic for sensitive data.

Rule 3.2: End-to-End Encryption for Team Data

REQUIRED:

• Encrypt data on client before sending to server
• Server never sees plaintext passwords
• Decrypt only on authorized client devices

RATIONALE: Zero-trust architecture - don't trust the server, encrypt everything client-side.

ENFORCEMENT: Server logs must show only encrypted blobs, no plaintext.

Rule 3.3: No Sensitive Data in URLs

PROHIBITED:

• Passwords in query parameters (?password=secret123)
• API keys in URL paths
• Tokens in URL fragments

ALLOWED:

• Session tokens in headers (Authorization: Bearer ...)
• Encrypted blobs in POST body

RATIONALE: URLs are logged by proxies, CDNs, browser history - never put secrets there.

ENFORCEMENT: URL inspection must show no sensitive data in query params.

Category 4: Authentication & Access Control

Rule 4.1: Multi-Factor Authentication Encouraged

REQUIRED (Enterprise):

• MFA for admin accounts (TOTP, hardware keys)
• MFA enforcement configurable per organization

ENCOURAGED (Teams/Personal):

• Optional MFA for all users
• Clear documentation of MFA benefits

PROHIBITED:

• SMS-based MFA (SIM swapping attacks)
• Email-based MFA (email compromise attacks)

ENFORCEMENT: MFA implementation must use TOTP (RFC 6238) or FIDO2/WebAuthn.

Rule 4.2: Session Timeout & Auto-Lock

REQUIRED:

• Configurable session timeout (default: 15 minutes)
• Auto-lock on inactivity
• Require passphrase re-entry after lock

PROHIBITED:

• "Remember me" checkboxes that bypass passphrase
• Indefinite sessions (no timeout)
• Caching passphrase for auto-unlock

ENFORCEMENT: QA must verify auto-lock works, no cached passphrases.

Rule 4.3: Least Privilege Access

REQUIRED:

• Users only see passwords they're authorized to access
• Admins explicitly grant access (no default access)
• Revocation immediately effective

PROHIBITED:

• "View all passwords" default permission
• Passwords accessible without explicit grant

ENFORCEMENT: Access control tests must verify authorization checks.

Category 5: Compliance & Audit

Rule 5.1: Immutable Audit Logs

REQUIRED:

• All password access logged to blockchain (immutable)
• Log includes: who, what, when, where (device ID)
• Logs cannot be deleted or modified (append-only)

PROHIBITED:

• Editable audit logs
• Deleting logs to hide activity
• Logs without sufficient detail for forensics

ENFORCEMENT: Blockchain validation must verify immutability.

Rule 5.2: Admin-Only Audit Access

REQUIRED:

• Only team admins can view audit logs
• Members cannot see other members' activity
• Audit access itself is audited

PROHIBITED:

• Members viewing full audit trail
• Anonymous audit entries (every action tracked to user + device)

ENFORCEMENT: UI must enforce admin-only audit page access.

Rule 5.3: Data Retention & Right to Erasure

REQUIRED:

• Document data retention policies (e.g., "Audit logs retained 7 years")
• Support GDPR "right to be forgotten" (delete user data on request)
• Encryption keys for deleted users destroyed (data unrecoverable)

PROHIBITED:

• Retaining user data indefinitely without documented policy
• Ignoring data deletion requests (GDPR violation)

ENFORCEMENT: Compliance review must verify data retention documentation.

Category 6: Code Quality & Security

Rule 6.1: No Custom Cryptography

PROHIBITED:

• Writing custom encryption algorithms
• Implementing own hashing functions
• "Rolling your own crypto"

REQUIRED:

• Use established libraries (NaCl, libsodium, OpenSSL)
• Use standard algorithms (AES-256, Argon2id, PBKDF2)
• Regular updates to crypto libraries (patch vulnerabilities)

RATIONALE: Cryptography is hard. Use expert-reviewed implementations.

ENFORCEMENT: Code review must verify only standard crypto libraries used.

Rule 6.2: Input Validation & Sanitization

REQUIRED:

• Validate all user input (length, format, type)
• Sanitize input before processing (prevent injection attacks)
• Whitelist allowed characters (don't just blacklist bad ones)

PROHIBITED:

• Trusting user input without validation
• SQL injection vulnerabilities (use parameterized queries)
• XSS vulnerabilities (escape HTML output)

ENFORCEMENT: Security audit must verify input validation on all endpoints.

Rule 6.3: Secure Error Handling

REQUIRED:

• User-friendly error messages (no stack traces)
• Technical details logged server-side only
• No information leakage in errors (e.g., "User exists" vs "Invalid credentials")

PROHIBITED:

• Showing stack traces to users
• Error messages that reveal system internals
• Timing attacks via error messages (e.g., "wrong password" in 5ms, "user not found" in 50ms)

ENFORCEMENT: QA must verify error messages are user-friendly, no leakage.

Rule 6.4: Regular Security Audits

REQUIRED:

• External security audit before v1.0 launch
• Penetration testing annually
• Dependency vulnerability scanning (Snyk, Dependabot)

PROHIBITED:

• Shipping without security review
• Ignoring known vulnerabilities

ENFORCEMENT: Release checklist must include security audit completion.

Category 7: User Experience & Education

Rule 7.1: Security Without Friction

PRINCIPLE: Security features must be usable. If security is too difficult, users will work around it.

REQUIRED:

• Clear error messages (actionable guidance)
• Reasonable defaults (15-min timeout, not 1-min)
• Progressive disclosure (advanced features hidden until needed)

PROHIBITED:

• Security theater (features that look secure but aren't)
• Unusable security (so complex users bypass it)

ENFORCEMENT: UX testing must verify security features are understandable.

Rule 7.2: User Education Over Restrictions

PRINCIPLE: Educate users on security best practices, don't just lock them out.

REQUIRED:

• Onboarding explains why passphrases matter
• Tooltips explain security features
• Documentation on threat models and mitigations

PROHIBITED:

• Cryptic security warnings with no explanation
• Assuming users understand cryptography

ENFORCEMENT: Documentation review must verify clear security explanations.

Rule 7.3: Transparency & Trust

PRINCIPLE: Users should understand how their data is protected.

REQUIRED:

• Clear documentation of encryption methods
• Open-source core libraries (after patent filing)
• White papers on security architecture

PROHIBITED:

• "Security through obscurity" (hiding implementation)
• Claiming security without explanation

ENFORCEMENT: Marketing review must verify claims are documented.

Category 8: Emergency & Disaster Recovery

Rule 8.1: Emergency Access Must Be Audited

REQUIRED (Enterprise):

• Master key access for emergency situations
• Multi-signature requirement (2-of-3 executives)
• Every master key use creates critical alert + audit entry

PROHIBITED:

• Backdoors without audit trail
• Single-person emergency access (no checks and balances)

ENFORCEMENT: Compliance audit must verify master key access is logged.

Rule 8.2: Backup & Export

REQUIRED:

• Users can export encrypted vault (backup)
• Export includes all data (passwords, audit log)
• Backup encrypted with user's passphrase (not separate key)

PROHIBITED:

• Plaintext exports
• Backups without encryption
• Cloud backups without user consent

ENFORCEMENT: Export functionality must produce encrypted output only.

Rule 8.3: No Single Point of Failure

REQUIRED:

• Dual-key architecture (can't lose both)
• Team members can't lose access if one admin unavailable
• Documented disaster recovery procedures

PROHIBITED:

• Single admin with no backup
• Data loss if one person forgets passphrase

ENFORCEMENT: Architecture review must verify redundancy.

Category 9: Third-Party Integrations

Rule 9.1: Minimize Attack Surface

PRINCIPLE: Every dependency is a potential vulnerability.

REQUIRED:

• Audit all third-party libraries before use
• Pin dependency versions (no automatic updates without review)
• Monitor for CVEs in dependencies

PROHIBITED:

• Installing dependencies without security review
• Using deprecated or unmaintained libraries

ENFORCEMENT: Dependency audit before every release.

Rule 9.2: Zero Trust for External Services

PRINCIPLE: Don't trust external services with sensitive data.

REQUIRED:

• Encrypt data before sending to cloud storage
• API keys rotated regularly
• OAuth tokens with minimal scope

PROHIBITED:

• Sending plaintext data to third-party APIs
• Trusting external services with encryption keys

ENFORCEMENT: Network audit must verify encrypted data transmission.

Category 10: PhantomKey-Specific Rules

Rule 10.1: Zero-Persistence is Non-Negotiable

PRINCIPLE: This is our core differentiator. Never compromise on zero-persistence.

REQUIRED:

• Sensitive data in memory only during session
• Memory cleared on logout, lock, crash
• No exceptions for "performance" or "convenience"

PROHIBITED:

• Caching decrypted passwords to disk
• Storing keys "just for this session"
• Any feature that violates zero-persistence

ENFORCEMENT: Architecture review must verify zero-persistence maintained.

Rule 10.2: Hawking Blockchain Immutability

REQUIRED:

• Dual-chain architecture (password chain + audit chain)
• Blockchain validation on every access
• Tamper detection and alerts

PROHIBITED:

• Modifying blockchain history
• Deleting audit entries
• Non-blockchain storage for passwords (breaks immutability)

ENFORCEMENT: Blockchain integrity tests must pass on every build.

Rule 10.3: QuantumRotation Encouragement

REQUIRED:

• Remind users to rotate team passphrases quarterly
• UI prompts for passphrase rotation
• Audit log shows last rotation date

PROHIBITED:

• Mandatory rotation (NIST says this weakens security)
• Auto-expiring passphrases (users choose weak ones)

REFERENCE: NIST SP 800-63B Section 5.1.1.2: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."

ENFORCEMENT: UI must show rotation reminders, not force rotation.

Enforcement & Compliance

Code Review Checklist

Before merging any PR:

• No passwords/keys in plaintext
• No password hints or security questions
• No temp files with sensitive data
• No sensitive data in logs
• HTTPS for all network traffic
• Input validation on all endpoints
• User-friendly error messages (no stack traces)
• Memory cleared on logout
• Standard crypto libraries (no custom crypto)
• Zero-persistence maintained

Security Audit Checklist

Before each release:

• External penetration test completed
• Dependency vulnerability scan passed
• No known CVEs in dependencies
• Audit logs immutable and complete
• Emergency access procedures documented
• Compliance documentation up to date (NIST, PCI, HIPAA if applicable)

Compliance Documentation

Required for enterprise sales:

• SOC 2 Type II certification (or in progress)
• GDPR compliance documentation
• HIPAA compliance documentation (healthcare customers)
• PCI-DSS compliance documentation (payment data)

Rule Violations & Exceptions

Requesting an Exception

Process:

1. Document why the rule cannot be followed
2. Propose alternative mitigation (compensating control)
3. Get approval from CTO (Stan) + security auditor
4. Document exception in code comments + compliance docs

Example Exception:

RULE VIOLATION: Master key stored in HSM (violates Rule 1.3)
JUSTIFICATION: Emergency access requires persistent key
MITIGATION: Multi-signature (2-of-3), full audit trail, annual review
APPROVED BY: Stan Pressman (CTO), Security Auditor
EXPIRES: Annual review required

Reporting Rule Violations

If you discover a rule violation:

1. Create security incident ticket (private, not public GitHub)
2. Assess severity (critical, high, medium, low)
3. Patch immediately if critical (exploit possible)
4. Document in post-mortem

Updates to This Document

This is a living document. Rules evolve as threats evolve.

Update Process:

1. Propose rule change with rationale
2. Review with security team
3. Update this document
4. Notify all developers
5. Update code review checklist

Version History:

• v1.0 (2026-02-28): Initial codification of PhantomKey security rules

References & Standards

NIST Guidelines:

• NIST SP 800-63B: Digital Identity Guidelines (Authentication)
• NIST SP 800-53: Security and Privacy Controls
• NIST Cybersecurity Framework

Industry Standards:

• OWASP Top 10 (Web Application Security)
• CWE Top 25 (Common Weakness Enumeration)
• SANS Top 25 (Software Security Errors)

Compliance Frameworks:

• SOC 2 Type II (Service Organization Control)
• PCI-DSS (Payment Card Industry Data Security Standard)
• HIPAA (Health Insurance Portability and Accountability Act)
• GDPR (General Data Protection Regulation)

Cryptography References:

• RFC 8018: PBKDF2 (Password-Based Key Derivation)
• RFC 9106: Argon2 (Memory-Hard Key Derivation)
• RFC 6238: TOTP (Time-Based One-Time Password)

Conclusion

These rules are not suggestions - they are requirements.

If a feature violates these rules and no exception is granted, the feature does not ship. Period.

Security is not optional. It is our core value proposition. Every line of code must uphold these principles.

When in doubt, ask: "Does this maintain zero-persistence?" If no, redesign it.

Document Owner: Stan Pressman (CTO, PhantomKey Technologies)
Last Reviewed: 2026-02-28
Next Review: Quarterly (May 2026)

END OF DOCUMENT