Security Infrastructure
Callexa operates as the default phone and SMS handler on users' devices — a position of significant trust. We take that responsibility seriously. This Security Policy documents the technical, organizational, and procedural controls we implement to protect user data from unauthorized access, disclosure, alteration, and destruction. Security is built into every layer of the App, from the code we write to the infrastructure we run and the people we hire.
Purpose, Scope, and Security Philosophy
1.1 Purpose of This Policy
This Security Policy ("Policy") formally documents the security architecture, controls, standards, and procedures that Callexa (developed and operated by Inflancer Technologies, "we", "us", or "our") implements to protect the Callexa mobile application ("the App"), the data it processes, and the infrastructure on which it operates. This Policy serves multiple purposes: it provides transparency to our users about how their data is protected; it establishes binding internal standards for our engineering, operations, and support teams; it defines our obligations to third-party service providers who process data on our behalf; and it demonstrates our commitment to compliance with applicable security-related regulatory requirements.
1.2 Scope of Application
This Policy applies to:
- The Callexa mobile application and all versions thereof (Android and iOS)
- All backend infrastructure, APIs, databases, and cloud services operated by Callexa
- All third-party service providers (data processors) who access or process data on behalf of Callexa under a contractual relationship
- All personnel of Inflancer Technologies who develop, operate, maintain, or support the App or its infrastructure
- All user data processed by or on behalf of Callexa, including data processed locally on users' devices
1.3 Security Philosophy — Defense in Depth
Callexa's security architecture is built on a defense-in-depth model. This means we do not rely on any single security control to protect data; instead, we implement multiple overlapping layers of protection such that the failure of any one control does not result in a complete security failure. Our security approach is organized around five pillars:
| Security Pillar | Description |
|---|---|
| 1. Secure by Design | Security requirements are identified and addressed at the design phase of every feature, before a line of code is written. We apply threat modeling to anticipate attack vectors before they become vulnerabilities. |
| 2. Least Privilege | Every component of the system — users, services, APIs, personnel — operates with only the minimum permissions necessary to perform its specific function. Access rights are not accumulated; they are granted explicitly and reviewed regularly. |
| 3. Encryption Everywhere | Data is encrypted both in transit and at rest using modern, proven cryptographic standards. We do not store sensitive data in plaintext anywhere in our systems. |
| 4. Continuous Monitoring | We actively monitor our systems for anomalous activity, security events, and performance degradation. Automated alerts escalate to on-call engineers within defined response time windows. |
| 5. Assume Breach | We design our systems and response procedures on the assumption that a security incident will eventually occur. Our incident response plan is tested regularly so that if a breach does happen, our response is practiced, rapid, and effective. |
1.4 Relationship to Other Policies
This Security Policy is part of Callexa's integrated legal and governance framework. It should be read alongside:
- Privacy Policy — which describes what data is collected, how it is used, and your rights as a data subject
- Data Retention Policy — which defines how long each category of data is held and how it is securely deleted
- Terms and Conditions — which governs the contractual relationship between Callexa and its users
Encryption Standards
Encryption is one of the most critical controls in Callexa's security posture. We apply encryption at every point where data is stored or transmitted, using algorithms and configurations that meet or exceed current industry standards and recommendations from bodies such as NIST, OWASP, and the IETF.
2.1 Encryption in Transit
All network communication between the Callexa App and our backend servers is encrypted using Transport Layer Security (TLS). We enforce the following specific standards:
| Configuration Parameter | Standard Applied |
|---|---|
Minimum TLS Version | TLS 1.2. TLS 1.0 and 1.1 are explicitly disabled on all server endpoints. |
Preferred TLS Version | TLS 1.3, used preferentially where the client and server both support it. |
| Cipher Suite Policy | Only AEAD (Authenticated Encryption with Associated Data) cipher suites: AES-256-GCM and ChaCha20-Poly1305. |
| Perfect Forward Secrecy | Mandatory on all server endpoints via ephemeral Diffie-Hellman key exchange (ECDHE). |
| HSTS | Enabled with a minimum max-age of 1 year (31,536,000 seconds). |
| Certificate Pinning | The Callexa App validates the authenticity of our server's TLS certificate at the application layer. |
| Certificate Authority | Reputable public CA using RSA-2048 or ECDSA P-256 with SHA-256 signatures. |
2.2 Encryption at Rest — Device (Local Data)
The majority of sensitive user data processed by Callexa — SMS messages, call logs, contacts — is stored locally on the user's device. This data is protected by the device's native encryption mechanisms:
| Platform | Encryption Implementation |
|---|---|
| Android — App Sensitive Data | Stored using EncryptedSharedPreferences and EncryptedFile, backed by the Android Keystore system. Hardware-backed where available (TEE/SE). |
| Android — Device Encryption | Android Full-Disk Encryption (FDE) or File-Based Encryption (FBE) protects all data stored on the device partition. |
| iOS — App Sensitive Data | Stored in the iOS Keychain, using hardware-backed encryption (Secure Enclave on modern devices). |
| iOS — Device Encryption | Hardware-level encryption (AES-256) for all stored data, used in conjunction with the device passcode. |
| Cross-Platform Storage | Utilizes the Flutter Secure Storage package, delegating to Android Keystore and iOS Keychain respectively. |
2.3 Encryption at Rest — Server-Side Data
Business Account profile data and verification documents stored on our servers are encrypted at rest:
- Database encryption: All data at rest is encrypted using AES-256 at the storage volume level.
- Object storage: Business profile images and verification documents are encrypted using AES-256 with server-managed keys.
- Verification document vault: Documents are stored in a higher-security storage environment with HSM-backed encryption keys.
- Key management: Encryption keys are rotated on a defined schedule and access is strictly audit-logged.
Application Security
3.1 Secure Development Lifecycle (SDLC)
Security is integrated into every phase of the App's development lifecycle:
| SDLC Phase | Security Activities Performed |
|---|---|
| Requirements & Design | Threat modeling is conducted for all new features affecting user data or permissions. |
| Development | Secure coding guidelines aligned with OWASP MASVS. Peer code review is mandatory for all sensitive changes. |
| Testing | SAST tools scan code on every pull request. Dynamic testing (DAST) is conducted on pre-release builds. |
| Build & Release | Signed with Callexa's private code-signing certificate in a controlled CI/CD environment. |
| Post-Release Monitoring | Continuous monitoring of crash reports, anomalous error rates, and security alerts. |
3.2.1 Anti-Tampering and Root/Jailbreak Detection
The Callexa App implements runtime checks to detect whether it is running on a compromised (rooted/jailbroken) device. Upon detection:
- Displays a clear warning to the user about the elevated security risk.
- Disables storage of sensitive session credentials in potentially compromised secure storage.
- May restrict access to sensitive features pending user acknowledgement.
3.2.4 Prevention of Data Leakage
Callexa implements multiple controls to prevent unintentional disclosure of sensitive data:
- Screen overlay protection: Uses FLAG_SECURE on Android to prevent screenshots, recordings, or thumbnails in task switchers.
- Clipboard protection: Does not automatically copy sensitive content without explicit user action.
- Logging controls: No personal data is written to system logs in production builds. Debug logging is disabled.
- Autocomplete restriction: Disabled for sensitive text input fields to prevent keyboard caching.
- Backup restrictions: Sensitive data is excluded from Android auto-backups to Google Drive.
3.4.1 User Authentication (Business Accounts)
Business Account access follows these security standards:
- Password hashing: Modern adaptive algorithms (bcrypt or Argon2id) with unique salts.
- Complexity requirements: Minimum 12 characters, encouraging passphrases.
- Account lockout: Enforced after 5 failed attempts.
- Multi-Factor Authentication (MFA): Available and recommended via TOTP or push notifications.
- Secure password resets: Time-limited (1 hour), single-use tokens.
Infrastructure and Cloud Security
4.1 Network Security
| Control | Implementation Detail |
|---|---|
| VPC Isolation | All backend services are in a private VPC; no direct public internet access to databases. |
| Firewall / Security Groups | Strict ingress/egress rules on a whitelist basis. |
| Web Application Firewall (WAF) | Deployed to filter common attack patterns (SQLi, XSS, etc.). |
| DDoS Protection | Cloud-native DDoS mitigation enabled for all public endpoints. |
| Intrusion Detection System | IDS monitors internal VPC traffic for anomalies and lateral movement. |
| Private Connectivity | Internal communication occurs over private network interfaces. |
4.4 Secrets Management
API keys and credentials are managed securely:
- No secrets are hardcoded or checked into version control.
- Stored in a dedicated secrets management service (HashiCorp Vault or cloud-native equivalent).
- Rotated regularly: DB passwords (90 days), API keys (180 days).
- Scoped to minimum required per service.
- Scanning tools run on every commit to detect accidental leaks.
Third-Party and Supply Chain Security
5.1 Third-Party SDK and Library Assessment
Before any third-party library is incorporated, it undergoes a security review covering vendor reputation, open-source code review, known vulnerability checks (NVD/GitHub Advsiory), and minimum permission verification.
5.3 Third-Party Service Provider Security Requirements
| Requirement Category | Specific Requirements | Enforcement |
|---|---|---|
| Certifications | ISO 27001, SOC 2 Type II, or equivalent. | Contractual obligation |
| DPA | Formally executed Data Processing Agreement. | Legally binding contract |
| Breach Notification | Must notify Callexa within 24 hours of awareness. | Contractual obligation |
| Encryption | TLS 1.2+ in transit and AES-256 at rest. | Contractual + Validation |
| Access Control | Least-privilege and MFA mandatory. | Contractual obligation |
| Right to Audit | Callexa reserves the right to audit practices. | Contractual right |
Organizational and Personnel Security
6.1 Hiring and Background Checks
All candidates for sensitive roles undergo identity verification and background screening (where permitted by law) before receiving an offer.
6.2 Security Training and Awareness
- Mandatory security onboarding for all new personnel.
- Annual security refresher training for all staff.
- Role-specific secure development training for engineers.
- Regular simulated phishing campaigns to assess awareness.
6.4 Offboarding
Revocation of all system access (cloud, code, DB) within 4 hours of a contributor's last working day. Devices are remotely wiped and recovered.
Vulnerability Management and Penetration Testing
7.1 Internal Vulnerability Scanning
| Severity | Remediation SLA |
|---|---|
| Critical (CVSS 9.0+) | 24 Hours |
| High (CVSS 7.0+) | 7 Days |
| Medium (CVSS 4.0+) | 30 Days |
| Low (CVSS 0.1+) | 90 Days |
7.2 Penetration Testing
Annual penetration tests are conducted by qualified third-party security firms against the App (Android/iOS) and backend APIs.
Incident Response and Breach Notification
8.1 Incident Classification
| Severity Level | Definition and Examples |
|---|---|
| P1 — Critical | Active breach with confirmed exfiltration; ransomware; complete loss of service. |
| P2 — High | Suspected unauthorized access; successful exploitation without confirmed exfiltration. |
| P3 — Medium | Failed attack; vulnerability discovered in production; service degradation. |
| P4 — Low | Suspicious activity with low impact; minor policy violation. |
8.3 Breach Notification Obligations
| Notification Recipient | Timeframe and Content |
|---|---|
| Supervisory Authorities | Within 72 hours of awareness for risks to rights and freedoms. |
| Affected Users | Without undue delay (target 72h) where high risk is present. |
| Law Enforcement | As appropriate for suspected criminal activity. |
| App Store Partners | Google and Apple notified for app-level remediation needs. |
Privacy-Enhancing Security Controls
9.1 Local-First Architecture
Our primary security control is architecture. By processing SMS, calls, and contacts locally:
- No central server breach can expose user communications.
- No transmission intercept risk for sensitive private data.
- No centralized database for subpoenas or government demands.
- Your data remains safe even if Callexa as a company ceases to exist.
9.3 Anonymization in Analytics and Diagnostics
We apply strict anonymization where collection is necessary:
- Crash reports: Stripped of message content, contacts, and call details.
- Usage analytics: Aggregated behavior patterns only.
- Spam reports: Contains only immediately hashed (SHA-256) phone numbers.
Security Governance and Policy Management
10.1 Security Ownership
| Role | Security Responsibilities |
|---|---|
| CTO / Security Lead | Executive accountability and program approval. |
| Security Team | Owns monitoring, pentesting, and feature reviews. |
| Engineering Team | Responsible for secure coding and timely remediation. |
| Operations Team | Owns hardening, patching, and backup integrity. |
Contact and Responsible Disclosure
7.3 Responsible Disclosure (Bug Bounty)
Report vulnerabilities to security@callexa.app. We request a 90-day coordinated disclosure window. Safe harbor is provided for good-faith research.
| Contact Purpose | Details |
|---|---|
| Vulnerability Reports | security@callexa.app (PGP available) |
| Privacy Concerns | privacy@callexa.app |
| Legal Matters | legal@callexa.app |
| Urgent P1 Incidents | security@callexa.app (Subject: [URGENT]) |
Security is Not a State, But a Process
Callexa is committed to continuous improvement. We regularly update our protocols and undergo independent audits to stay ahead of emerging threats.