Security Features

Relevant source files

The following files were used as context for generating this wiki page:

• SECURITY.md
• V1_PRODUCTION_IMPLEMENTATION_PLAN.md
• android/app/src/main/kotlin/com/sovereign/communications/security/KeystoreManager.kt
• ios/SovereignCommunications/Security/CertificatePinningManager.swift
• CONTRIBUTING.md
• IMPLEMENTATION_SUMMARY.md
• TODO_AUDIT.md
• V1_LAUNCH_READY.md

Sovereign Communications (SC) is designed with a multi-layered security approach to ensure user privacy, data integrity, and communication confidentiality. Security is not a single feature but a core principle woven through the cryptographic foundation, platform-specific implementations, network protocols, and data handling policies. The system employs end-to-end encryption, decentralized architecture, and various defense mechanisms to protect against a wide range of threats.

This document outlines the key security features of the SC platform, from the core cryptographic primitives to platform-specific hardware security and network-level protections. For more details on the project's threat model and security policies, see the Security Policy.

Sources: SECURITY.md, CONTRIBUTING.md

Core Cryptography

The foundation of SC's security is its cryptographic stack, which uses modern, audited libraries (@noble/curves, @noble/ciphers) to prevent the introduction of custom, unaudited cryptographic code.

Sources: CONTRIBUTING.md:310-311, IMPLEMENTATION_SUMMARY.md:12-19

Primitive	Algorithm	Purpose
Signatures	Ed25519	Provides message authentication and author verification.
Key Exchange	X25519	Establishes shared secrets for symmetric encryption via Elliptic Curve Diffie-Hellman (ECDH).
Encryption	XChaCha20-Poly1305	Authenticated Encryption with Associated Data (AEAD) cipher for encrypting message content.
Forward Secrecy	Double Ratchet	The documentation mentions the use of the Double Ratchet algorithm (Signal Protocol) for Perfect Forward Secrecy, ensuring session keys rotate automatically.

Sources: SECURITY.md:162-167, IMPLEMENTATION_SUMMARY.md:12-19

Platform-Specific Security

SC leverages native, hardware-backed security features on both Android and iOS to protect sensitive data like private keys.

Android: Hardware-Backed Keystore

The Android application utilizes the Android Keystore system to store cryptographic keys in a hardware-backed secure environment (like StrongBox, if available). This prevents key extraction even on a compromised or rooted device. The KeystoreManager.kt class is central to this architecture.

Key Functions:

• Key Generation: Creates hardware-backed keys for database passphrases, identity, and backup encryption.
• Passphrase Management: Encrypts and securely stores the database passphrase, automatically decrypting it on app startup.
• Secure Storage: Manages the lifecycle of keys within the Android Keystore.

Sources: V1_LAUNCH_READY.md:49, 81-84, TODO_AUDIT.md:63-67

The diagram below shows the class structure for managing keys on Android.

iOS: Certificate Pinning

To combat Man-in-the-Middle (MITM) attacks, the iOS application implements certificate pinning. The CertificatePinningManager.swift is responsible for validating the server's certificate against a known, trusted public key hash. In a production environment, this manager is configured to "fail closed," meaning any certificate mismatch will result in a connection failure, preventing potential eavesdropping.

Sources: V1_COMPLETENESS_AUDIT.md:180-184, SECURITY.md:171

The sequence diagram illustrates how the certificate pinning manager handles a network authentication challenge.

Network Security & Anti-Spam

These features protect the network from abuse and analysis.

Proof-of-Work (PoW)

To prevent spam and denial-of-service attacks, SC incorporates a Proof-of-Work mechanism. Before a message is accepted by a peer, it must contain a valid PoW. This requires the sender to expend computational resources, making it costly to send messages in bulk. The difficulty of the PoW can be adjusted.

The process is as follows:

1. The sender generates a PoW by finding a nonce that, when hashed with the message data, produces a hash with a certain number of leading zeros (the difficulty).
2. The PoW is attached to the message.
3. The receiver verifies the PoW. If valid, the message is processed. If invalid, it is discarded.

Note: The implementation details in core/src/mesh/proof-of-work.ts were not available for analysis, but its purpose is documented.

Sources: SECURITY.md:174

Traffic Padding

To defend against traffic analysis, where an attacker tries to infer information from the size of encrypted messages, SC implements traffic padding. This feature pads messages to a uniform or random size, obscuring the true size of the underlying content.

Note: The implementation details in core/src/mesh/traffic-padding.ts were not available for analysis, but its purpose is documented.

Sources: SECURITY.md:177-178

Rate Limiting

To prevent spam and resource exhaustion, the system implements per-user rate limiting for messages and file transfers. This is managed by the RateLimiter class.

Limit	Default Value
Messages per Minute	60
Messages per Hour	1000
Files per Hour	100

This system tracks timestamps of user actions and rejects requests that exceed the configured thresholds.

Sources: V1_PRODUCTION_IMPLEMENTATION_PLAN.md:200-206

Data and Privacy Protection

These features focus on protecting user data at rest and ensuring user privacy.

Input Sanitization

To prevent Cross-Site Scripting (XSS) attacks, all user-generated content is sanitized before being displayed. The implementation uses DOMPurify to strip all HTML tags from inputs, ensuring that no malicious scripts can be rendered in the application.

// Example from V1_PRODUCTION_IMPLEMENTATION_PLAN.md
import DOMPurify from 'dompurify';

export function sanitizeHTML(html: string): string {
  return DOMPurify.sanitize(html, {
    ALLOWED_TAGS: [], // No HTML tags allowed in messages
    ALLOWED_ATTR: [],
    KEEP_CONTENT: true
  });
}

Sources: V1_PRODUCTION_IMPLEMENTATION_PLAN.md:141-160

File Upload Validation

To prevent the transfer of malicious files, all file uploads are strictly validated against a set of rules before being processed.

Validation Rule	Limit / Configuration
Max Size	100 MB
Max Files per Message	10
Allowed MIME Types	Images, videos, audio, PDF, text, archives
Blocked Extensions	.exe, .bat, .js, .jar, .app, etc.
Filename Sanitization	Path traversal and special characters are removed.

Sources: V1_PRODUCTION_IMPLEMENTATION_PLAN.md:181-200

Secure Deletion

SC provides a secure deletion feature to overwrite data on disk, making it difficult to recover. This is intended to work on traditional hard drives. However, the documentation notes that this method may not be fully effective on modern SSDs due to wear-leveling algorithms.

Note: The implementation details in core/src/secure-deletion.ts were not available for analysis, but its purpose and limitations are documented.

Sources: SECURITY.md:179, 205-206

Invite and Sharing Security

Invite links are cryptographically signed by the issuer and can be configured with short-lived, one-time-use tokens to prevent replay attacks or abuse.

Sources: SECURITY.md:182-186

Security Policy and Vulnerability Reporting

The project maintains a formal security policy and encourages responsible disclosure of vulnerabilities.

Reporting a Vulnerability

Vulnerabilities should not be reported via public GitHub issues. Instead, they should be reported privately through:

1. GitHub Security Advisories (Preferred)
2. Email to security@sovereigncommunications.app

Sources: SECURITY.md:13-20

Severity Ratings

The project uses CVSS 3.1 to rate vulnerabilities, with clear definitions for Critical, High, Medium, and Low severities. Recognition is offered to reporters based on the severity of the finding.

Severity	CVSS 3.1 Score	Example
Critical	9.0 - 10.0	Remote code execution, breaking E2E encryption.
High	7.0 - 8.9	Authentication bypass, privilege escalation.
Medium	4.0 - 6.9	Cross-site scripting (XSS), information disclosure.
Low	0.1 - 3.9	Minor information disclosure, best practice violations.

Sources: SECURITY.md:83-112

Conclusion

The security of the Sovereign Communications platform is built on a robust, layered defense strategy. It combines a strong cryptographic foundation with platform-specific hardware security, network-level protections against spam and analysis, and strict data validation rules. The formal security policy and commitment to responsible disclosure further reinforce the project's dedication to maintaining a secure and private communication environment.