Skip to content

Open-Source Security Architecture

Philosophy

SAWABONA follows Kerckhoffs's principle: security should depend on the secrecy of keys, not the secrecy of algorithms. This is why we open-source our cryptographic algorithms while keeping keys and secrets private.

"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

What's Public (Open-Source)

Algorithms & Protocols

  • Geometric Proof: Geometric proof algorithm for license validation
  • Validation Protocol: Complete specification of license validation flow
  • Key Derivation: PBKDF2-HMAC-SHA256 and Argon2 implementations
  • Encryption: AES-256-GCM with authenticated encryption
  • Signatures: Ed25519 elliptic curve signatures

Documentation

  • API specifications and endpoints
  • Database schemas and migrations
  • Configuration options
  • Deployment procedures
  • Security architecture

Code

  • All source code on GitHub (public repository)
  • Implementation details visible for expert review
  • Test vectors and security tests
  • Build and deployment scripts

What's Private (Secrets)

Cryptographic Keys

  • HSM Master Keys: Hardware Security Module keys (never leave HSM)
  • Client Diversified Keys: Per-client encryption keys
  • JWT Secrets: Token signing secrets
  • API Keys: Admin and service API keys
  • Payment Provider Keys: Stripe, Adyen, PayStack, etc.

Sensitive Data

  • Customer data and license information
  • Payment information
  • Audit logs containing sensitive operations
  • Database credentials and connection strings

Security Through Transparency

Why Open Algorithms Are Stronger

  1. Expert Review: Cryptographers can audit the implementation
  2. Vulnerability Discovery: Security researchers can find and report issues
  3. Community Trust: Transparency builds confidence in security
  4. Rapid Patching: Issues can be fixed quickly with community help
  5. No Security Through Obscurity: Hidden algorithms are often weaker

How We Maintain Security

  1. Key Secrecy: All keys are kept private and secure
  2. Secure Defaults: Strong algorithms and parameters by default
  3. Constant-Time Operations: Protection against timing attacks
  4. Memory Zeroization: Sensitive data cleared after use
  5. Audit Logging: All cryptographic operations logged

Key Management

Deployment Tiers

Tier HSM Type Use Case Key Storage
Community SoftwareHSM Development/Testing Local filesystem (dev only)
SaaS/Pro Cloud KMS Production SaaS AWS KMS or Azure Key Vault Standard
Enterprise Dedicated HSM High-security deployments AWS CloudHSM or Azure Key Vault HSM

Key Rotation

  • Automatic: Keys rotated every 90 days
  • Manual: Can be rotated on-demand
  • Graceful: Old keys kept for decryption during transition
  • Audited: All rotations logged for compliance

Threat Model

What Open-Source Doesn't Weaken

  • Cryptographic Strength: Algorithm security is independent of secrecy
  • Key Security: Keys remain private regardless of algorithm visibility
  • Implementation Quality: Code review improves security
  • Vulnerability Response: Faster patching with community help

What We Protect

  • Keys: Never exposed, always encrypted at rest
  • Credentials: Stored securely in HSM or secrets manager
  • Customer Data: Encrypted with client-specific keys
  • Audit Logs: Immutable and tamper-evident

See THREAT-MODEL.md for detailed threat analysis.

Audit Trail

Cryptographic Operations Logged

  • Key generation and rotation
  • Encryption/decryption operations
  • Signature creation and verification
  • Key access and usage
  • Failed authentication attempts

Compliance

  • GDPR: Data protection and audit logging
  • PCI-DSS: Encryption and key management
  • SOC 2: Security controls and monitoring
  • ISO 27001: Information security management

Deployment Security

Production Hardening Checklist

  • [ ] HSTS enabled (auto-enabled in production)
  • [ ] Debug mode disabled
  • [ ] All secrets rotated from defaults
  • [ ] JWT secret >= 64 characters
  • [ ] Encryption keys generated and configured
  • [ ] Database encryption enabled
  • [ ] Rate limiting enabled
  • [ ] CORS origins restricted
  • [ ] Security headers configured
  • [ ] Monitoring and alerting enabled

See PRODUCTION-SECURITY-CHECKLIST.md for complete checklist.

Responsible Disclosure

Reporting Vulnerabilities

If you discover a vulnerability in our open-source code:

  1. Do NOT create a public GitHub issue
  2. Report privately via security@sawabona.dev
  3. Include details: Description, impact, reproduction steps
  4. Allow time: We'll coordinate disclosure timing with you

See SECURITY.md for full vulnerability reporting process.

Compliance

Standards & Best Practices

Key Principles

  1. Algorithms are public, keys are private
  2. Security through transparency, not obscurity
  3. Expert review improves security
  4. Audit everything, trust nothing
  5. Fail securely, never leak secrets

Last Updated: 2025-12-04 Version: 1.0