Version: 1.0
Last Updated: 2026-04-17
Owner: Mazhai Technologies Security Team
Contact: security@mazhai.org

1. Supported Versions
2. Reporting Security Vulnerabilities
3. Incident Response Procedures
4. Key Rotation Policy
5. Cryptographic Material Management
6. SOC Integration
7. Compliance Frameworks

Security updates are backported to all Active and Maintenance versions.

We follow responsible disclosure practices. Please report vulnerabilities privately before public disclosure.

Email: security@mazhai.org
PGP Key: security@mazhai.org.asc
HackerOne: hackerone.com/mazhai
Bug Bounty: Up to $10,000 for critical RASP bypasses

• ✅ RASP/Frida detection bypasses
• ✅ Genesis Anchor extraction techniques
• ✅ Phantom Channel MITM attacks
• ✅ E2EE protocol weaknesses
• ✅ Keystore/Keychain extraction
• ✅ Memory dump vulnerabilities

• ❌ Theoretical attacks without PoC
• ❌ Social engineering
• ❌ Physical device access (out of scope)
• ❌ Attacks requiring root/jailbreak (expected behavior)

• Genesis keys extracted from production builds
• RASP bypass published publicly
• Mass device compromise detected
• Backend API key leakage

Response: Immediate page to on-call, war room within 1 hour, public disclosure if customer-affecting.

• Single SDK version bypass technique
• Partial key exposure (development only)
• Phantom Channel DoS vulnerability
• SDK tampering in supply chain

Response: Work hours response, patch within 72 hours.

• Documentation inaccuracies affecting security
• Build system vulnerabilities
• Third-party dependency CVEs

Response: Scheduled fix in next sprint.

// Automated response chain
1. Device sends encrypted crash telemetry with incident ID
2. Backend logs to SIEM (Splunk/Datadog) with high severity
3. Device fingerprint added to temporary watchlist
4. SOC analyst notified via PagerDuty
5. If >100 incidents in 10 minutes → auto-scale threat rules

// 3-phase response
1. SHRED phase: Device wipes all secrets (irreversible)
2. SEVER phase: Network blackhole activated
3. FREEZE phase: Device UI locked, user must force-stop

// Backend actions:
- Revoke all session tokens for device fingerprint
- Add fingerprint to 24-hour cool-down list
- Alert customer security team if enterprise license
- Preserve incident forensics (encrypted blob)

# If build system is suspected compromised:
1. Halt all releases immediately
2. Rotate all CI/CD secrets (GitHub, AWS, signing keys)
3. Audit all commits since last known-good build
4. Rebuild from clean environment with new keys
5. Force-update all production apps (emergency release)
6. Notify customers via security advisory

Dual-key support allows gradual rotation:

# application.yml during rotation
aran:
  crypto:
    active-key-id: "v2"
    keys:
      v1:
        aes-key: ${ARAN_AES_KEY_V1}  # old, expiring
        hmac-secret: ${ARAN_HMAC_V1}
        valid-until: "2026-07-17"
      v2:
        aes-key: ${ARAN_AES_KEY_V2}  # new, primary
        hmac-secret: ${ARAN_HMAC_V2}
        valid-from: "2026-04-17"

SDK accepts both keys during 7-day grace period, then rejects old keys.

# 1. Generate new keys
NEW_AES=$(openssl rand -hex 32)
NEW_HMAC=$(openssl rand -hex 32)

# 2. Update GitHub Actions secrets
github secrets set ARAN_AES_KEY_V2 "$NEW_AES" --repo techdhamo/aran
github secrets set ARAN_HMAC_V2 "$NEW_HMAC" --repo techdhamo/aran

# 3. Trigger production build
gh workflow run production-release.yml

# 4. Monitor for decryption failures (should be 0% during grace period)
# 5. After 7 days, remove old keys

# AES-256: os.urandom(32) or secrets.token_bytes(32)
# HMAC-256: Same entropy source
# Salt: Always 16 bytes, random per-build
# IV: 12 bytes, random per-encryption (never reused)

🚫 NEVER:

• Commit plaintext keys to git (even "test" keys)
• Share keys via email/Slack
• Hardcode keys in source files
• Use same keys across dev/staging/prod
• Skip rotation due to "convenience"

✅ ALWAYS:

• Use separate keys per environment
• Rotate on employee offboarding
• Audit access logs quarterly
• Test disaster recovery ("oops, all keys leaked" drill)

# Critical: Mass Scorched Earth activation
index=aran source="telemetry" event_type="SCORCHED_EARTH"
| stats count by device_fingerprint, _time
| where count > 5
| alert severity=critical "Mass device wipe detected"

# High: MITM attempts on Phantom Channel
index=aran source="phantom_sync" result="CERT_PIN_MISMATCH"
| stats count by src_ip
| where count > 10
| alert severity=high "Possible proxy/MITM attack"

# Medium: Frida detection spikes
index=aran source="rasp" threat="FRIDA_DETECTED"
| timechart span=1h count
| where count > 100
| alert severity=medium "Unusual Frida detection rate"

# monitors/aran-critical.yaml
alerts:
  - name: "Aran Genesis Decryption Failures"
    query: "sum:aran.genesis.decrypt_fail{*}.as_count() > 10"
    message: "@pagerduty-SOC-urgent Potential key compromise"
    priority: P1

  - name: "Phantom Channel MITM Detection"
    query: "avg:aran.phantom.mitm_detected{*} > 0"
    message: "@security-team MITM attempt on config sync"
    priority: P2

When Scorched Earth activates, preserved data:

{
  "incident_id": "uuid-v4",
  "timestamp": "ISO8601",
  "device_fingerprint": "SHA-256 hash",
  "threat_mask": "0x7FFF",
  "reason": "MITM detected on Phantom Channel",
  "app_version": "1.0.0",
  "os_version": "Android 14",
  "sdk_version": "1.0.0",
  "encrypted_blob": "AES-256-GCM encrypted device state"
}

Retention: 90 days encrypted, then purged per GDPR.

• ✅ Data minimization: No PII in telemetry
• ✅ Right to erasure: Scorched Earth = immediate wipe
• ✅ Encryption: AES-256-GCM for all data
• ✅ Breach notification: 72-hour automated alert

Document Classification: PUBLIC
Next Review: 2026-07-17