ANSSI R226 Interception Compliance Documentation

Document Purpose: This document provides technical specifications required for ANSSI R226 authorization under Articles R226-3 and R226-7 of the French Penal Code for the OmniMessage SMS Service Center (SMSc).

Classification: Regulatory Compliance Documentation

Target Authority: Agence nationale de la sécurité des systèmes d'information (ANSSI)

Regulation: R226 - Protection of Correspondence Privacy and Lawful Interception

1. DETAILED TECHNICAL SPECIFICATIONS

1.1 Commercial Technical Datasheet

Product Name: OmniMessage SMSc (SMS Service Center) Product Type: Telecommunications Message Center Primary Function: SMS message routing, storage, and delivery Network Protocols: REST API (HTTPS), SMS protocols (SMPP, IMS, SS7/MAP via external frontends) Deployment Model: On-premises server application Technology Stack: Elixir/Erlang, Phoenix Framework, Mnesia, MySQL/PostgreSQL

Core Capabilities

Message Processing:

Centralized SMS message queue with REST API
Protocol-agnostic design supporting SMPP, IMS, SS7/MAP frontends
Dynamic routing engine with prefix-based routing
Retry logic with exponential backoff
Message expiration and dead letter queue handling
Call Detail Record (CDR) generation and archival
Performance: ~1,750 messages/second insert rate, 150 million messages/day capacity

Message Storage:

Active Message Queue: Mnesia in-memory database with optional disc persistence
- Primary storage: RAM for ultra-fast access (sub-millisecond latency)
- Disc backup: disc_copies mode writes to disk for crash recovery
- Automatic recovery: Messages survive system restarts
- Retention: Configurable (default 24 hours), then automatic cleanup
Long-term CDR Archive: MySQL/PostgreSQL database (separate from message queue)
- CDRs written when messages are delivered, expired, failed, or rejected
- SQL database used ONLY for CDR export/archival, NOT for active message operations
- No performance impact on message routing (async write)
Two-tier Architecture Benefits:
- Active queue: Blazing fast (1,750 msg/sec) with no SQL bottleneck
- CDR archive: Long-term retention (months/years) for billing and lawful interception
- Clean separation: Message operations never touch SQL
Cluster support for high availability (Mnesia replication across nodes)

Network Interfaces:

REST API: HTTPS (port 8443) for external frontend communication
Control Panel: HTTPS (port 8086) for web-based management
Frontend Protocols: SMPP, IMS, SS7/MAP (via external gateway applications)
Database: MySQL/PostgreSQL for CDR storage

Routing and Processing:

Dynamic SMS routing with runtime configuration updates
Prefix-based matching (calling/called numbers)
Source SMSC and type filtering
Priority and weight-based load balancing
Number translation and normalization
ENUM (E.164 Number Mapping) DNS lookup support
Auto-reply and message drop capabilities
Per-route charging control (CGRates integration)

📖 Complete architecture and features documented in README.md

1.2 Interception Capabilities

1.2.1 Message Acquisition

SMS Message Capture:

The OmniMessage SMSc processes all SMS messages between subscribers and external networks
Full access to message metadata and content including:
- Source MSISDN (mobile number)
- Destination MSISDN (mobile number)
- Source IMSI (International Mobile Subscriber Identity)
- Destination IMSI
- Message body (text content)
- Raw PDU (Protocol Data Unit) data
- TP-DCS (Data Coding Scheme) information
- Message encoding (GSM7, UCS-2, 8-bit, Latin-1)
- Multipart message indicators and reassembly data
- User Data Header (UDH) information

Message Metadata Acquisition:

Complete Call Detail Records (CDR) stored in database with:
- Message ID (unique identifier)
- Calling number (source MSISDN)
- Called number (destination MSISDN)
- Submission timestamp (when message entered system)
- Delivery timestamp (when message was delivered)
- Expiry timestamp (when message expired if undeliverable)
- Status (delivered, expired, failed, rejected)
- Delivery attempts count
- Message parts (for concatenated/multi-part SMS)
- Source SMSC identifier
- Destination SMSC identifier
- Origin node (Erlang cluster node name)
- Destination node (for distributed deployments)
- Deadletter flag (retry exhaustion indicator)

📖 Complete CDR schema documented in CDR_SCHEMA.md

Message Queue Access:

Real-time message queue monitoring
REST API endpoints for message retrieval
Database queries for historical message search
Filter capabilities by:
- Phone number (source/destination)
- SMSC gateway
- Time range
- Message status
- Delivery attempts

📖 Complete API documentation in API_REFERENCE.md

1.2.2 Data Processing Capabilities

Message Storage Architecture (Two-Tier System):

The SMSc uses a sophisticated two-tier storage architecture that separates operational message processing from long-term archival:

Tier 1: Active Message Queue (Mnesia)

Purpose: Real-time message routing and delivery operations
Technology: Erlang Mnesia distributed database
Storage Mode: In-memory with disc_copies backup
- Primary storage in RAM for maximum speed
- Automatic disc synchronization for crash recovery
- Messages persist across system restarts
Performance: Sub-millisecond read/write operations
Retention: Short-term (default 24 hours), configurable
Cleanup: Automatic archival to CDR database, then deletion from Mnesia
Operations: All message queue operations (insert, update, delivery status, routing)
Critical Feature: SQL database is NEVER queried during message routing/delivery

Tier 2: CDR Archive (MySQL/PostgreSQL)

Purpose: Long-term storage for billing, analytics, and lawful interception
Technology: Traditional SQL database (MySQL or PostgreSQL)
Write Trigger: CDRs written ONLY when messages reach final state:
- Message delivered successfully
- Message expired (exceeded validity period)
- Message permanently failed
- Message rejected by routing rules
Write Mode: Asynchronous batch writing (no impact on message routing performance)
Retention: Long-term (months to years), configurable per regulatory requirements
Operations: Historical queries, reporting, compliance, lawful interception
Access: SQL queries, REST API (future), CSV/JSON export

Key Architectural Benefits:

Performance: Active routing operations never touch SQL (no database bottleneck)
Scalability: Mnesia handles 1,750+ messages/second without SQL overhead
Reliability: Disc_copies mode ensures no message loss on crash
Compliance: CDR database provides permanent audit trail
Separation of Concerns: Operational data vs. archival data clearly separated

Message Lifecycle:

Message submitted → Stored in Mnesia (RAM + disc backup)
Message routed → Mnesia query (ultra-fast)
Message delivered/expired → CDR written to SQL (async)
After 24h → Message deleted from Mnesia (cleanup worker)
CDR remains in SQL → Available for lawful interception queries (years)

Data Retention and Retrieval:

Configurable message body retention or deletion for privacy
Binary data preservation (raw PDU storage in both Mnesia and CDR)
Full-text search capability (if enabled on CDR database)
Indexed CDR fields for fast lawful interception queries

Frontend Tracking:

Real-time tracking of external SMSC frontends (SMPP, IMS, MAP gateways)
Frontend registration with heartbeat monitoring
Health status tracking (active/expired)
Uptime/downtime history
IP address and hostname tracking
Frontend-specific configuration logging

1.2.3 Analysis Capabilities

Real-Time Monitoring:

Web UI dashboard showing:
- Active message queue
- Message submission and delivery
- Routing decisions and gateway selection
- Frontend gateway status
- System resource utilization
Prometheus metrics integration for operational monitoring
Performance metrics (throughput, latency, success rates)

📖 Complete monitoring guide in OPERATIONS_GUIDE.md 📖 Metrics documentation in METRICS.md

Historical Analysis:

CDR database queryable by:
- Time range
- Calling/called party number
- Message status
- SMSC gateway
- Delivery attempts
- Message content (full-text search if enabled)
Statistical analysis capabilities:
- Message volume by hour/day/month
- Success/failure rates by route
- Average delivery times
- Multi-part message analysis
- Failed delivery patterns

Subscriber Tracking:

Message history by phone number (MSISDN)
IMSI-based tracking (when available from IMS/MAP frontends)
Call pattern analysis
Communication party correlation
Temporal analysis (message frequency, timing patterns)

Network Analytics:

Route performance metrics
Gateway availability and health
Message flow visualization
Cluster node distribution (multi-node deployments)
Delivery attempt analysis
Retry pattern analysis

Number Intelligence:

E.164 number normalization
Country/region identification from number prefix
Number translation and rewriting rules
ENUM DNS lookup for routing intelligence
Prefix-based routing decisions

📖 Number translation guide in number_translation_guide.md 📖 Routing guide in sms_routing_guide.md

1.3 Countermeasure Capabilities

1.3.1 Privacy Protection Mechanisms

Communication Confidentiality:

HTTPS/TLS for REST API communications
Certificate-based authentication
Database connection encryption (TLS support)
Configurable message body deletion after delivery

Access Control:

Web UI access control
API authentication mechanisms
Database access controls
Frontend registration authentication

Audit Logging:

Complete system event logging
Message submission/delivery logging
Configuration change tracking
Administrative action logging
Structured logging with configurable levels

1.3.2 Data Protection Features

Message Privacy:

Configurable message body deletion after delivery
Message body excluded from UI display (optional)
Message body excluded from exports (optional)
CDR message body field can be set to NULL for privacy

Database Security:

MySQL table encryption support (ENCRYPTION='Y')
PostgreSQL transparent data encryption support
Database access role separation
Read-only user accounts for analytics
Restricted access to message content

System Hardening:

Minimal exposed network ports
TLS certificate management
Secure configuration storage
Environment-based configuration separation
Cluster security with Erlang distribution protocol

1.4 Storage Architecture: Mnesia + SQL Two-Tier Design

Overview

The OmniMessage SMSc employs a unique two-tier storage architecture specifically designed to separate high-performance operational message processing from long-term compliance and archival storage.

Tier 1: Mnesia In-Memory Message Queue

What is Mnesia?

Distributed database built into Erlang/OTP runtime
Hybrid storage: Primary in-memory with automatic disc backup
ACID-compliant transactions
Cluster replication across multiple nodes

Storage Mode: disc_copies

In-Memory Primary: All active messages stored in RAM
- Lightning-fast read/write operations (sub-millisecond)
- No disk I/O during normal message routing operations
- Enables 1,750+ messages/second throughput
Disc Backup (Automatic): Mnesia synchronizes RAM to disk
- Writes happen asynchronously in background
- Disk copy updated on every transaction commit
- Crash recovery: System restarts with all messages intact
- Location: Mnesia.*/ directory in application data

Message Lifecycle in Mnesia:

Message arrives via REST API → Inserted into Mnesia RAM + disc backup
Routing engine queries Mnesia → Instant response (memory access)
External gateway polls for messages → Mnesia query (memory access)
Gateway updates delivery status → Mnesia update (memory + disc)
After delivery/expiry → Message marked for cleanup
Cleanup worker (24h default) → Message deleted from Mnesia

Critical Performance Feature:

ZERO SQL database queries during active message routing/delivery
SQL is completely bypassed for operational message processing
This eliminates the traditional SMS-C bottleneck (database I/O)

Tier 2: SQL Database for CDR Export/Archival

What is CDR (Call Detail Record)?

Permanent audit record of message metadata and content
Written to MySQL or PostgreSQL database
Used for billing, analytics, compliance, and lawful interception

When CDRs are Written: CDR records are created ONLY when messages reach a final state:

✅ Message delivered successfully
✅ Message expired (exceeded validity period without delivery)
✅ Message permanently failed (invalid number, routing error)
✅ Message rejected (routing rules, validation failure)

How CDRs are Written:

Asynchronous batch writing: CDRs written in background worker process
No blocking: Message routing never waits for SQL write
Batched inserts: Multiple CDRs grouped (default 100) and written together
Flush interval: 100ms default (configurable)
Error handling: Failed CDR writes logged, message processing continues

# Configuration in config/runtime.exs
config :sms_c,
  batch_insert_batch_size: 100,          # Batch size for CDR writes
  batch_insert_flush_interval_ms: 100    # Flush interval

SQL Database Purpose:

❌ NOT used for: Active message queue operations
❌ NOT used for: Message routing decisions
❌ NOT used for: Real-time message delivery
✅ ONLY used for: Long-term CDR archival and historical queries
✅ ONLY used for: Lawful interception queries (months/years of history)
✅ ONLY used for: Billing and analytics reports

Architecture Diagram

Legend:

Solid lines: Synchronous operations (real-time)
Dashed lines: Asynchronous operations (background)
Green: High-performance tier (in-memory)
Blue: Archival tier (persistent SQL)

Lawful Interception Implications

Recent Messages (< 24 hours):

Accessible via Mnesia (REST API queries)
Ultra-fast retrieval
Full message content available
Real-time monitoring possible

Historical Messages (> 24 hours):

Accessible via SQL database (CDR table)
Standard SQL query performance
Full message metadata always available
Message body available (unless privacy mode enabled)

Compliance Benefits:

No data loss: Disc_copies mode ensures messages survive crashes
Permanent audit trail: CDRs retained for years in SQL database
Performance: Lawful interception queries don't impact message routing
Flexibility: Recent messages (Mnesia) + historical messages (SQL) both accessible

1.5 Multi-Protocol Frontend Integration Architecture

The OmniMessage SMSc employs a protocol-agnostic core design that interfaces with external protocol-specific gateways (frontends) via a unified REST API. This architecture allows lawful interception to capture messages regardless of which telecommunications protocol was used to send or receive them.

Architecture Overview

Frontend Protocol Integration Details

1. IMS/SIP Frontend Integration

IMS networks use SIP protocol for SMS-over-IP messaging. The IMS gateway translates between SIP and the SMSc REST API.

IMS-Specific Interception Data:

Source/Destination IMSI (from IMS registration)
P-Asserted-Identity SIP headers
SIP Call-ID for correlation
IMS network location (P-Access-Network-Info)
Subscriber profiles from IMS HSS

2. SMPP Frontend Integration

SMPP is the industry-standard protocol for SMS aggregators and service providers. The SMPP gateway translates PDU-based SMPP messages to REST API calls.

SMPP-Specific Interception Data:

Complete SMPP PDU (binary format preserved)
Data Coding Scheme (DCS) details
User Data Header (UDH) for concatenated messages
ESME system_id (customer identification)
TON/NPI numbering plan information
Registered delivery flags

3. SS7/MAP Frontend Integration

Legacy circuit-switched networks use SS7 MAP protocol for SMS. The MAP gateway translates between SS7 signaling and REST API.

SS7/MAP-Specific Interception Data:

IMSI from MAP messages
Global Title (GT) addresses
MSC/VLR address (network element identification)
SCCP calling/called party addresses
MAP operation codes
TP-User-Data binary format

Unified Interception Across All Protocols

Key Benefit for Lawful Interception: Regardless of which protocol was used (IMS/SIP, SMPP, or SS7/MAP), all messages converge in the SMSc core with normalized data structure, enabling:

Protocol-Agnostic Monitoring: Single interception point captures all message types
Unified CDR Format: All protocols write to same CDR schema
Cross-Protocol Correlation: Track messages across protocol boundaries
Complete Metadata Preservation: Protocol-specific fields preserved in CDR

Data Flow Summary:

Protocol Identification in CDR:

source_smsc field indicates frontend protocol (e.g., "ims.gateway-01", "smpp.customer123", "map.msc-01")
Enables filtering and analysis by protocol type
Lawful interception queries can target specific protocols or all protocols

1.6 Technical Architecture for Lawful Interception

Lawful Interception Integration Points

The two-tier storage architecture provides multiple access points for lawful interception, optimized for both real-time monitoring (Mnesia) and historical analysis (SQL).

1. REST API Access for Recent Messages (Mnesia):

Access to active messages in the Mnesia queue (typically last 24 hours):

API Endpoints for Real-Time Interception:

GET /api/messages - List active messages with filtering
GET /api/messages/{id} - Get specific message details (from Mnesia)
GET /api/messages/get_by_smsc?smsc=X - Get messages by gateway
All queries hit Mnesia (in-memory) for instant response

Note: These endpoints query the active Mnesia message queue, providing access to messages currently being processed or recently delivered (within retention period).

Query Parameters:

Filter by source/destination MSISDN
Filter by time range
Filter by SMSC gateway
Filter by message status
Sort and pagination support

2. CDR Database Direct Access for Historical Messages (SQL):

Access to archived messages in the SQL database (all delivered/expired/failed messages):

Direct SQL Access:

Read-only database credentials for authorized systems
SQL query access to cdrs table (permanent audit trail)
Access Method: Standard SQL client (mysql, psql, DBeaver, etc.)
Data Source: Only archived messages (not active queue)
Indexed fields for efficient searching:
- calling_number (indexed) - Source phone number
- called_number (indexed) - Destination phone number
- message_id (indexed) - Unique message identifier
- submission_time (indexed) - When message entered system
- status (indexed) - Final delivery status
- dest_smsc (indexed) - Gateway used for delivery

Note: CDR database contains permanent records of all processed messages. This is the primary data source for historical lawful interception queries (months/years of data).

3. Real-Time Message Feed (PubSub):

Phoenix PubSub integration for real-time events
Message submission notifications
Message delivery notifications
Message status change events
Configurable event filtering by criteria
WebSocket support for live monitoring

4. Batch Export Interface:

CSV export of CDR records
JSON export for programmatic access
Configurable export fields
Time-range based exports
Privacy-aware exports (optional message body exclusion)

ETSI Lawful Interception Standard Interfaces

The OmniMessage SMSc provides the foundation for implementing ETSI-compliant lawful interception interfaces. While the SMSc core does not natively implement X1/X2/X3 interfaces, it provides all necessary data access points that can be integrated with external Lawful Interception Mediation Function (LIMF) systems.

Standard ETSI LI Interfaces:

Interface Descriptions:

X1 Interface - Administration Function:

Purpose: Warrant and target provisioning from law enforcement to interception system
Direction: LEMF → LIMF (bidirectional)
Functions:
- Activate/deactivate interception for specific targets (MSISDNs, IMSIs)
- Set interception duration and validity period
- Configure filtering criteria (phone numbers, time windows)
- Retrieve interception status
Integration with SMSc:
- LIMF maintains target list (warrant database)
- LIMF queries SMSc CDR/API for matching messages
- LIMF filters based on X1 provisioned criteria

X2 Interface - IRI (Intercept Related Information) Delivery:

Purpose: Deliver message metadata to law enforcement
Direction: LIMF → LEMF (one-way)
Data Format: ETSI TS 102 232-x compliant XML/ASN.1
Content from SMSc CDR:
- Message ID
- Calling number (source MSISDN)
- Called number (destination MSISDN)
- IMSI (source and destination, if available)
- Submission timestamp
- Delivery timestamp
- Message status (delivered/failed/expired)
- Delivery attempts
- SMSC gateway information (source/destination)
- Network location (if available)
Integration with SMSc:
- LIMF queries CDR database for target phone numbers
- LIMF transforms CDR records into ETSI IRI format
- LIMF delivers IRI to LEMF via X2

X3 Interface - CC (Content of Communication) Delivery:

Purpose: Deliver actual message content to law enforcement
Direction: LIMF → LEMF (one-way)
Data Format: ETSI TS 102 232-x compliant
Content from SMSc:
- Message body (text content)
- Raw PDU (binary SMS data)
- Character encoding information
- Multipart message segments
- TP-DCS information
- User Data Header (UDH)
Integration with SMSc:
- LIMF retrieves message content from CDR message_body field
- LIMF retrieves raw PDU data if available
- LIMF packages content in ETSI CC format
- LIMF delivers CC to LEMF via X3

Implementation Architecture:

SMSc Data Mapping to LI Interfaces:

SMSc Data Field	X2 (IRI)	X3 (CC)	CDR Table Column
Message ID	✅ Correlation ID	✅ Reference	`message_id`
Calling Number	✅ Party A	-	`calling_number`
Called Number	✅ Party B	-	`called_number`
Submission Time	✅ Timestamp	-	`submission_time`
Delivery Time	✅ Completion	-	`delivery_time`
Status	✅ Result	-	`status`
Message Body	-	✅ Content	`message_body`
Raw PDU	-	✅ Binary	(Mnesia/CDR)
Source SMSC	✅ Network element	-	`source_smsc`
Dest SMSC	✅ Network element	-	`dest_smsc`
IMSI	✅ Subscriber ID	-	(Via frontends)

LIMF Integration Options:

Option 1: Polling Architecture

LIMF periodically queries CDR database (every 1-60 seconds)
SQL query filters by target phone numbers from X1 warrant list
Low complexity, easy to implement
Slight delay between message delivery and LI delivery

Option 2: Real-Time Feed Architecture

SMSc PubSub publishes message events
LIMF subscribes to real-time message stream
LIMF filters based on target list
Near-zero latency for lawful interception
Requires custom integration development

Option 3: Hybrid Architecture

Recent messages: Real-time PubSub feed (< 24 hours)
Historical messages: CDR database polling
Optimal balance of latency and reliability

Interception Triggering Mechanisms

Target-Based Interception:

Phone number matching (MSISDN)
IMSI-based targeting (when available)
Configurable watch lists
Database views for target isolation
API filtering by target identifiers

Event-Based Interception:

All messages to/from specific numbers
Messages via specific SMSC gateways
Messages with specific characteristics (multi-part, failed delivery, etc.)
Geographic routing (via ENUM or prefix matching)

Time-Based Interception:

Date/time range filtering in CDR queries
Retention period enforcement
Automatic archival of old messages
Configurable data retention policies

Example SQL Queries for Lawful Interception:

-- Get all messages for target number
SELECT * FROM cdrs
WHERE calling_number = '+33612345678'
   OR called_number = '+33612345678'
ORDER BY submission_time DESC;

-- Get messages in specific time window
SELECT * FROM cdrs
WHERE (calling_number = '+33612345678' OR called_number = '+33612345678')
  AND submission_time BETWEEN '2025-11-01 00:00:00' AND '2025-11-30 23:59:59'
ORDER BY submission_time;

-- Get conversation between two parties
SELECT * FROM cdrs
WHERE (calling_number = '+33612345678' AND called_number = '+33687654321')
   OR (calling_number = '+33687654321' AND called_number = '+33612345678')
ORDER BY submission_time;

2. ENCRYPTION AND CRYPTANALYSIS CAPABILITIES

2.1 Cryptographic Capabilities Overview

The OmniMessage SMSc implements cryptographic mechanisms for securing communications and protecting sensitive data. This section documents all cryptographic capabilities in accordance with ANSSI requirements.

2.2 Transport Layer Encryption

2.2.1 TLS/SSL Implementation

Supported Protocols:

TLS 1.2 (RFC 5246)
TLS 1.3 (RFC 8446) - Recommended
SSL 2.0/3.0: NOT SUPPORTED (known vulnerabilities)
TLS 1.0/1.1: DEPRECATED (not recommended)

Implementation:

Erlang/OTP SSL/TLS library (cryptographically validated)
Cowboy web server with TLS support
Phoenix Framework HTTPS endpoints

Cipher Suites:

The system uses Erlang/OTP's default secure cipher suite selection, which includes:

Preferred - TLS 1.3:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256

Supported - TLS 1.2:

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256

Security Features:

Perfect Forward Secrecy (PFS) via ECDHE/DHE key exchange
Strong Diffie-Hellman groups (2048-bit minimum)
Elliptic Curve Cryptography support
Server Name Indication (SNI) support

Certificate Management:

X.509 certificate support
RSA key sizes: 2048-bit minimum, 4096-bit recommended
ECDSA support
Certificate chain validation
Self-signed certificates (development only)
External CA integration

TLS Configuration Location:

# config/runtime.exs
config :api_ex,
  api: %{
    enable_tls: true,
    tls_cert_path: "priv/cert/omnitouch.crt",
    tls_key_path: "priv/cert/omnitouch.pem"
  }

📖 Complete configuration reference in CONFIGURATION.md

Applications:

HTTPS for REST API (port 8443)
HTTPS for web control panel (port 8086)
Database connections (MySQL/PostgreSQL over TLS)

2.3 Data Encryption at Rest

2.3.1 Database Encryption

MySQL/MariaDB Encryption:

Table-level encryption support
AES-256 encryption algorithm
Transparent data encryption (TDE)

-- Enable encryption for CDR table
ALTER TABLE cdrs ENCRYPTION='Y';

PostgreSQL Encryption:

Transparent data encryption support
Filesystem-level encryption
Column-level encryption (pgcrypto extension)

2.3.2 Mnesia Disc Storage

Mnesia Database:

Disc copies storage for message persistence
File system-level encryption recommended (LUKS, dm-crypt)
Memory protection via Erlang VM isolation

2.3.3 File System Encryption

Sensitive Data Storage:

Configuration files: Filesystem encryption recommended
Private keys: File permissions (0600) + filesystem encryption
Log files: Configurable encryption for archived logs
CDR exports: Encrypted storage for sensitive exports

Key Storage:

TLS certificates and keys stored in priv/cert/
File-based keystores with restricted permissions
Secure key rotation procedures

2.4 Authentication and Access Control

2.4.1 API Authentication

REST API Security:

HTTPS/TLS transport encryption mandatory
Header-based authentication (SMSc header for frontend identification)
IP-based access control (firewall level)
Certificate-based client authentication (optional)

Frontend Registration:

Unique frontend identification (name, type, IP, hostname)
Heartbeat-based authentication
Expiration-based session management (90-second timeout)
Frontend tracking and monitoring

2.4.2 Database Authentication

Database Access Control:

Username/password authentication
TLS/SSL connection support
IP-based connection restrictions
Role-based access control (RBAC)

Configuration:

# config/runtime.exs
config :sms_c, SmsC.Repo,
  username: "omnitouch",
  password: "omnitouch2024",  # Should use strong passwords in production
  hostname: "localhost",
  ssl: true  # Enable TLS for database connections

Access Control Recommendations:

-- Create read-only user for law enforcement access
CREATE USER 'li_readonly'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT ON sms_c.cdrs TO 'li_readonly'@'%';

-- Create limited user without message body access
CREATE USER 'analytics'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT (id, message_id, calling_number, called_number,
              source_smsc, dest_smsc, submission_time, delivery_time,
              status, delivery_attempts)
ON sms_c.cdrs TO 'analytics'@'%';

2.5 Cryptographic Algorithm Details

2.5.1 Hashing Algorithms

Available in Erlang/OTP:

SHA-256, SHA-384, SHA-512 (recommended)
SHA-1 (deprecated, legacy compatibility only)
MD5 (deprecated, not used for security)
BLAKE2 (available in modern OTP versions)

Usage:

Message fingerprinting (duplicate detection)
Data integrity verification
Audit log integrity

2.5.2 Symmetric Encryption

Available Algorithms:

AES (Advanced Encryption Standard)
- AES-128-GCM
- AES-256-GCM
- AES-128-CBC
- AES-256-CBC
ChaCha20-Poly1305

Key Sizes:

128-bit (minimum)
256-bit (recommended)

Usage:

TLS session encryption
Database encryption at rest
Optional message body encryption

2.5.3 Asymmetric Encryption

Supported Algorithms:

RSA (2048-bit minimum, 4096-bit recommended)
ECDSA (Elliptic Curve Digital Signature Algorithm)
- P-256, P-384, P-521 curves
Ed25519 (EdDSA)

Usage:

TLS certificate authentication
Digital signatures
Key exchange

2.6 SMS Protocol Security

2.6.1 SMS Message Encoding

Character Encoding Support:

GSM 7-bit (standard SMS encoding)
UCS-2 (Unicode, 16-bit)
8-bit binary data
Latin-1

TP-DCS (Data Coding Scheme):

Message class indication
Compression flags
Coding group specification
Character set identification

No Native SMS Encryption:

SMS protocol does not provide end-to-end encryption
Message content accessible at SMSc level
Enables lawful interception as required

2.6.2 Protocol Security Considerations

SMPP Protocol (External Frontend):

Username/password authentication at SMPP level
TLS support available (SMPP over TLS)
Bind authentication

IMS Protocol (External Frontend):

SIP-based messaging
SIP authentication mechanisms
Integration with IMS core network security

SS7/MAP Protocol (External Frontend):

SS7 network security
MAP protocol authentication
SCCP/TCAP layer security

Note: Protocol-specific security is implemented in external frontend gateways, not in the SMSc core.

2.7 Cryptanalysis and Security Assessment Capabilities

2.7.1 Protocol Analysis Tools

Built-in Debugging Capabilities:

Comprehensive logging system
Message flow tracing
API request/response logging
Database query logging
Error and exception tracking

External Integration:

Standard logging output (stdout/files)
PCAP capture support for network analysis
Database query logging for forensics
Prometheus metrics export

2.7.2 Vulnerability Assessment Considerations

Known Limitations:

SMS protocol inherently unencrypted (by design, enables lawful interception)
Database credentials in configuration files (should use secrets management)
Self-signed certificate support (development/testing only)

Security Hardening Recommendations:

Use strong TLS cipher suites
Implement database connection encryption
Use external secrets management (Vault, AWS Secrets Manager)
Regular security updates for Erlang/OTP and dependencies
Firewall restrictions on API ports
IP whitelisting for frontend access

Security Testing:

Regular dependency vulnerability scanning
Penetration testing support
TLS configuration validation
Database security audits
Access control review

2.8 Key Management Infrastructure

2.8.1 Key Generation

TLS Certificate Generation:

# Generate private key (RSA 4096-bit)
openssl genrsa -out omnitouch.pem 4096

# Generate certificate signing request
openssl req -new -key omnitouch.pem -out omnitouch.csr

# Self-signed certificate (development)
openssl x509 -req -days 365 -in omnitouch.csr -signkey omnitouch.pem -out omnitouch.crt

# Production: Obtain certificate from trusted CA

Random Number Generation:

Erlang/OTP CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
System entropy pool (/dev/urandom)
Strong randomness for session keys, IDs, tokens

2.8.2 Key Storage and Protection

Private Key Storage:

File system with restricted permissions (0600)
Stored in priv/cert/ directory
PEM format (optionally encrypted)
Secure backup procedures

Key Rotation:

TLS certificate renewal (annually recommended)
Database credential rotation
API token rotation (if implemented)

2.8.3 Key Distribution

Certificate Distribution:

Manual installation in priv/cert/
Configuration file references
ACME protocol support possible (Let's Encrypt)

Symmetric Key Distribution:

Out-of-band key exchange for database credentials
Diffie-Hellman key agreement in TLS
No cleartext key transmission

2.9 Compliance and Standards

Cryptographic Standards Compliance:

NIST SP 800-52: TLS guidelines
NIST SP 800-131A: Cryptographic algorithm transitions
RFC 7525: TLS recommendations
ETSI TS 133 310: Network security (for IMS integration)

French Cryptography Regulations:

No export-restricted cryptography (all standard algorithms)
Cryptographic means declaration (if applicable)
ANSSI cryptographic product certification (if required)

2.10 Cryptanalysis Resistance

2.10.1 Design Principles

Defense Against Cryptanalysis:

No custom/proprietary cryptographic algorithms
Industry-standard, peer-reviewed algorithms only
Regular security updates for cryptographic libraries
Deprecation of weak algorithms
Use of authenticated encryption (GCM, Poly1305)

2.10.2 Operational Security

Key Rotation:

TLS certificate renewal procedures
Session key rotation (per-session for TLS)
Database credential rotation policies

Monitoring and Detection:

Failed authentication logging
Certificate expiration monitoring
TLS handshake failure logging
Anomaly detection for encryption failures
Security event alerting

3. INTERCEPTION CONTROL AND AUTHORIZATION

3.1 Access Control for Lawful Interception

Administrative Authorization:

System administrator access required for configuration
Database-level access controls for CDR queries
API access restricted by IP/authentication
Audit logging of all access

Legal Framework Integration:

Interception warrant tracking (external system integration)
Target identifier authorization lists (database views)
Time-limited queries (SQL WHERE clauses)
Automatic enforcement via access policies

3.2 Data Retention and Privacy

Retention Policies:

Active message retention: Configurable (default 24 hours in Mnesia)
CDR retention: Configurable (typical 6 months to 2 years)
Automatic archival from Mnesia to SQL
Automatic purging of old CDRs (cron-based)

Privacy Protections:

Message body deletion option after delivery
Message body exclusion from UI/exports
Database encryption at rest
Access logging and monitoring
Minimal data collection principle

Configuration:

# config/runtime.exs
config :sms_c,
  # Mnesia message retention before archival
  message_retention_hours: 24,

  # Delete message body after delivery for privacy
  delete_message_body_after_delivery: false,  # Set true for privacy mode

  # CDR writing control
  cdr_enabled: true,

  # Batch archival settings
  batch_insert_batch_size: 100,
  batch_insert_flush_interval_ms: 100

📖 See CONFIGURATION.md for all retention settings

3.3 Handover Interfaces for Law Enforcement

Standard Interfaces:

1. REST API Access:

HTTPS endpoints for message retrieval
JSON format data exchange
Authentication and authorization
Query filtering by target criteria

2. Direct Database Access:

Read-only SQL credentials
Standard SQL queries
CDR table access
Indexed search capabilities

3. Batch Export:

CSV export format
JSON export format
Time-range based exports
Configurable field selection

Delivery Formats:

IRI (Intercept Related Information):

CDR metadata fields:
- Message ID
- Calling/called numbers
- Timestamps (submission, delivery, expiry)
- Status
- Delivery attempts
- SMSC routing information
- Node information (cluster tracking)

CC (Content of Communication):

Message body (text content)
Raw PDU data
Encoding information
Multipart message assembly

Export Example:

# CSV export for law enforcement
mysql -u li_readonly -p -D sms_c -e "
SELECT
  message_id,
  calling_number,
  called_number,
  message_body,
  submission_time,
  delivery_time,
  status
FROM cdrs
WHERE (calling_number = '+33612345678' OR called_number = '+33612345678')
  AND submission_time BETWEEN '2025-11-01' AND '2025-11-30'
ORDER BY submission_time
" --batch --silent | sed 's/\t/,/g' > interception_report.csv

4. SYSTEM SECURITY AND INTEGRITY

4.1 Application Security

Elixir/Erlang Security:

Erlang VM isolation and sandboxing
Process isolation and supervision
Crash recovery and fault tolerance
No buffer overflow vulnerabilities (managed runtime)

Dependency Management:

Dependency version locking (mix.lock)
Security vulnerability scanning
Regular dependency updates
Minimal dependency footprint

4.2 Network Security

Network Exposure:

Minimal exposed ports:
- 8443 (HTTPS REST API)
- 8086 (HTTPS Control Panel)
- 3306/5432 (Database - should be firewalled)
Firewall configuration recommended
IP whitelisting for frontend access
DMZ deployment for internet-facing services

Network Segmentation:

Separate management network
Isolated database network
Frontend gateway network separation
Cluster communication network (Erlang distribution)

4.3 Monitoring and Intrusion Detection

Logging Capabilities:

Structured application logging
Configurable log levels
Log rotation and archival
Syslog integration support
Centralized logging (ELK stack compatible)

Security Event Monitoring:

Failed authentication attempts
Unusual message patterns
Database connection failures
TLS handshake failures
System resource anomalies

Metrics and Alerting:

Prometheus metrics export
Message throughput monitoring
Error rate tracking
System resource utilization
Custom alert rules

📖 Complete monitoring documentation in OPERATIONS_GUIDE.md and METRICS.md

4.4 High Availability and Disaster Recovery

Cluster Support:

Erlang distributed cluster capability
Mnesia replication across nodes
Automatic failover
Node discovery and joining

Data Redundancy:

Mnesia disc_copies on all cluster nodes
SQL database replication (MySQL/PostgreSQL native)
CDR backup procedures
Configuration backup

Recovery Procedures:

Database backup and restore
Mnesia table recovery
Configuration restoration
Node replacement procedures

5. DOCUMENTATION REFERENCES

5.1 Technical Manuals

Available documentation in the project repository:

README.md - System overview, architecture, and features
CONFIGURATION.md - Complete configuration reference
API_REFERENCE.md - REST API documentation
OPERATIONS_GUIDE.md - Operational procedures and monitoring
CDR_SCHEMA.md - Call Detail Record database schema
sms_routing_guide.md - SMS routing configuration
number_translation_guide.md - Number normalization
METRICS.md - Prometheus metrics and monitoring
PERFORMANCE_TUNING.md - Performance optimization
TROUBLESHOOTING.md - Common issues and solutions

5.2 Security Certifications

Penetration Test Reports: [To be provided upon request]
Security Audit Reports: [To be provided upon request]
Vulnerability Assessments: [To be provided upon request]
Erlang/OTP Cryptographic Validation: Industry-standard cryptographic library

5.3 Compliance Documentation

ANSSI R226 Authorization Request: This document
Lawful Interception Compliance: As required by French telecommunications regulations
Data Protection Compliance: GDPR considerations for message data

6. CONTACT INFORMATION

Vendor/Operator Information:

Company Name: Omnitouch Network Services Pty Ltd
Address: PO BOX 296, QUINNS ROCKS WA 6030, AUSTRALIA
Contact Person: Compliance Team
Email: compliance@omnitouch.com.au

Technical Security Contact:

Name: Compliance Team
Email: compliance@omnitouch.com.au

Legal/Compliance Contact:

Name: Compliance Team
Email: compliance@omnitouch.com.au

APPENDICES

Appendix A: SMS Message Flow with Interception Points

A.1 Outbound SMS Flow (Mobile Terminated)

Legend: [INTERCEPTION POINT] = Points where lawful interception data is captured and stored

A.2 Inbound SMS Flow (Mobile Originated)

Appendix B: CDR Schema for Lawful Interception

The OmniMessage SMSc stores Call Detail Records in a SQL database (MySQL or PostgreSQL) for long-term retention and lawful interception access.

B.1 Key CDR Fields for Lawful Interception

Field Name	Type	Description	Interception Relevance
`id`	BIGINT	Auto-incrementing primary key	Record identifier
`message_id`	BIGINT	Unique message identifier	Session correlation
`calling_number`	VARCHAR(255)	Source MSISDN	Primary identifier for target tracking
`called_number`	VARCHAR(255)	Destination MSISDN	Target destination tracking
`source_smsc`	VARCHAR(255)	Source gateway identifier	Protocol/gateway tracking
`dest_smsc`	VARCHAR(255)	Destination gateway identifier	Routing information
`origin_node`	VARCHAR(255)	Erlang cluster node (origination)	System tracking
`destination_node`	VARCHAR(255)	Erlang cluster node (delivery)	Cluster distribution
`submission_time`	DATETIME	Message submission timestamp	Event timeline
`delivery_time`	DATETIME	Message delivery timestamp	Delivery confirmation
`expiry_time`	DATETIME	Message expiry timestamp	Failed delivery tracking
`status`	VARCHAR(50)	Message status (delivered/expired/failed/rejected)	Final disposition
`delivery_attempts`	INT	Number of delivery attempts	Retry analysis
`message_parts`	INT	Number of SMS segments	Concatenated message tracking
`deadletter`	BOOLEAN	Dead letter queue flag	Permanent failure indicator
`message_body`	TEXT	SMS message content	Message content (optional)
`inserted_at`	DATETIME	CDR creation timestamp	Audit trail
`updated_at`	DATETIME	CDR update timestamp	Modification tracking

📖 Complete schema documentation with SQL examples in CDR_SCHEMA.md

B.2 CDR Query Examples for Lawful Interception

Query all messages for target number:

SELECT * FROM cdrs
WHERE calling_number = '+33612345678'
   OR called_number = '+33612345678'
ORDER BY submission_time DESC;

Query messages within time window:

SELECT * FROM cdrs
WHERE (calling_number = '+33612345678' OR called_number = '+33612345678')
  AND submission_time BETWEEN '2025-11-01 00:00:00' AND '2025-11-30 23:59:59'
ORDER BY submission_time;

Export to CSV for law enforcement:

.mode csv
.output /tmp/interception_report.csv
SELECT message_id, calling_number, called_number, message_body,
       submission_time, delivery_time, status
FROM cdrs
WHERE calling_number = '+33612345678'
ORDER BY submission_time DESC;

B.3 CDR Database Access Methods

1. Direct SQL Access:

Read-only database credentials
Standard SQL queries
JDBC/ODBC connectivity
Database client tools (MySQL Workbench, pgAdmin)

2. REST API Access:

Future enhancement: REST API for CDR queries
JSON format responses
Authentication and authorization
Query parameter filtering

3. Batch Export:

CSV export via mysql/psql command-line
Automated export scripts
Scheduled exports via cron

B.4 CDR Retention and Privacy

Retention Configuration:

# config/runtime.exs
config :sms_c,
  # Delete message body after delivery (privacy mode)
  delete_message_body_after_delivery: false,  # true for privacy

  # Enable/disable CDR writing
  cdr_enabled: true,

  # Mnesia to CDR archival settings
  message_retention_hours: 24

Privacy Options:

Message body can be set to NULL after delivery
Database table encryption (MySQL ENCRYPTION='Y')
Column-level access restrictions
Masked exports for analytics

Appendix C: REST API Reference for Interception

C.1 Message Retrieval Endpoints

Get all messages:

GET /api/messages
Authorization: Bearer <token>

Get messages by SMSC:

GET /api/messages/get_by_smsc?smsc=gateway-name

Get specific message:

GET /api/messages/{id}

Response Format:

{
  "status": "success",
  "data": [
    {
      "id": 12345,
      "message_id": 12345,
      "source_msisdn": "+33612345678",
      "destination_msisdn": "+33687654321",
      "message_body": "Message content here",
      "source_smsc": "ims.gateway",
      "dest_smsc": "smpp.provider",
      "status": "delivered",
      "delivery_attempts": 1,
      "inserted_at": "2025-11-29T10:30:00Z",
      "deliver_time": "2025-11-29T10:30:05Z",
      "expires": "2025-11-30T10:30:00Z"
    }
  ]
}

📖 Complete API documentation in API_REFERENCE.md

C.2 Filtering and Search

Query Parameters:

source_smsc - Filter by source gateway
dest_smsc - Filter by destination gateway
Time-range filtering (via CDR database queries)
Status filtering (via CDR database queries)

Future Enhancements:

REST API for CDR queries
Advanced filtering by phone number
Date range filtering
Full-text search on message body

Appendix D: Configuration Examples

D.1 TLS Certificate Configuration

Generate TLS Certificate:

# Generate 4096-bit RSA private key
openssl genrsa -out priv/cert/omnitouch.pem 4096

# Generate certificate signing request
openssl req -new -key priv/cert/omnitouch.pem -out priv/cert/omnitouch.csr \
  -subj "/C=FR/ST=IDF/L=Paris/O=Omnitouch/CN=smsc.example.com"

# Self-signed certificate (development/testing)
openssl x509 -req -days 365 -in priv/cert/omnitouch.csr \
  -signkey priv/cert/omnitouch.pem -out priv/cert/omnitouch.crt

# Production: Submit CSR to trusted CA for signing

Configure in application:

# config/runtime.exs
config :api_ex,
  api: %{
    enable_tls: true,
    tls_cert_path: "priv/cert/omnitouch.crt",
    tls_key_path: "priv/cert/omnitouch.pem"
  }

D.2 Database Encryption Configuration

MySQL Table Encryption:

-- Enable encryption for CDR table
ALTER TABLE cdrs ENCRYPTION='Y';

-- Verify encryption status
SELECT TABLE_NAME, CREATE_OPTIONS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'sms_c' AND TABLE_NAME = 'cdrs';

PostgreSQL Connection Encryption:

# config/runtime.exs
config :sms_c, SmsC.Repo,
  username: "omnitouch",
  password: "secure_password",
  hostname: "localhost",
  database: "sms_c",
  ssl: true,
  ssl_opts: [
    verify: :verify_peer,
    cacertfile: "/path/to/ca.crt",
    certfile: "/path/to/client.crt",
    keyfile: "/path/to/client.key"
  ]

D.3 Privacy Configuration

Enable Message Body Deletion:

# config/runtime.exs
config :sms_c,
  # Delete message body after successful delivery
  delete_message_body_after_delivery: true,

  # Hide message body in UI
  hide_message_body_in_ui: true,

  # Hide message body in exports
  hide_message_body_in_export: true

Create Privacy-Preserving Database View:

-- Create view without message bodies for general analytics
CREATE VIEW cdrs_metadata AS
SELECT
  id, message_id, calling_number, called_number,
  source_smsc, dest_smsc, origin_node, destination_node,
  submission_time, delivery_time, expiry_time,
  status, delivery_attempts, message_parts, deadletter,
  inserted_at, updated_at
FROM cdrs;

-- Grant access to analytics users
GRANT SELECT ON cdrs_metadata TO 'analytics'@'%';

Appendix E: Glossary

Regulatory and Standards Bodies

ANSSI: Agence nationale de la sécurité des systèmes d'information - French National Cybersecurity Agency
ETSI: European Telecommunications Standards Institute
3GPP: 3rd Generation Partnership Project - Mobile telecommunications standards
IETF: Internet Engineering Task Force - Internet standards body

Telecommunications Terms

SMSc: SMS Service Center - Central system for SMS message routing and delivery
SMPP: Short Message Peer-to-Peer protocol - Industry standard for SMS exchange
ESME: External Short Message Entity - SMPP client application
IMS: IP Multimedia Subsystem - All-IP network architecture for multimedia services
SIP: Session Initiation Protocol - Signaling protocol for IMS messaging
P-CSCF: Proxy Call Session Control Function - IMS network entry point
S-CSCF: Serving Call Session Control Function - IMS session control
HSS: Home Subscriber Server - IMS subscriber database
SS7/MAP: Signaling System 7 / Mobile Application Part - Legacy mobile signaling protocols
MSC: Mobile Switching Center - Circuit-switched network element
VLR: Visitor Location Register - Subscriber location database
GT: Global Title - SS7 addressing scheme
SCCP: Signaling Connection Control Part - SS7 network layer
TCAP: Transaction Capabilities Application Part - SS7 application layer
MSISDN: Mobile Station International Subscriber Directory Number - Phone number
IMSI: International Mobile Subscriber Identity - Unique subscriber identifier
E.164: International numbering plan for telephone numbers
ENUM: E.164 Number Mapping - DNS-based phone number to URI mapping
PDU: Protocol Data Unit - Binary encoded SMS message
TP-DCS: Transfer Protocol Data Coding Scheme - SMS encoding specification
TP-DU: Transfer Protocol Data Unit - SMS-specific PDU format
UDH: User Data Header - Header for concatenated/special SMS messages
TON/NPI: Type of Number / Numbering Plan Indicator - Number format classification
GSM7: GSM 7-bit default alphabet - Standard SMS character encoding
UCS-2: Universal Character Set 2-byte - Unicode encoding for SMS

System Components

Mnesia: Erlang distributed database system - In-memory/disc storage
CDR: Call Detail Record - Billing and analytics record for messages
REST API: Representational State Transfer - HTTP-based API architecture
Phoenix: Elixir web framework
Cowboy: Erlang HTTP server
Ecto: Elixir database wrapper and query language
PubSub: Publish-Subscribe messaging pattern

Lawful Interception

LI: Lawful Interception - Legal monitoring of telecommunications
LIMF: Lawful Interception Mediation Function - System that interfaces between telecom network and law enforcement
LEMF: Law Enforcement Monitoring Facility - Law enforcement system receiving intercepted data
IRI: Intercept Related Information - Call/message metadata for law enforcement
CC: Content of Communication - Actual message content
X1 Interface: ETSI LI administrative interface - Warrant provisioning and target activation
X2 Interface: ETSI LI interface for IRI delivery - Metadata handover to law enforcement
X3 Interface: ETSI LI interface for CC delivery - Content handover to law enforcement
R226: Articles R226-3 and R226-7 of French Penal Code governing interception equipment
ETSI: European Telecommunications Standards Institute - Defines LI standards
ETSI TS 102 232: Technical specification for lawful interception handover interfaces

Message Processing

MT: Mobile Terminated - Outbound message to mobile subscriber
MO: Mobile Originated - Inbound message from mobile subscriber
DLR: Delivery Receipt - Confirmation of message delivery
Dead Letter: Message that failed delivery after all retry attempts
Exponential Backoff: Increasing retry delay (2min, 4min, 8min, etc.)

Security and Encryption

TLS: Transport Layer Security - Encryption protocol
PFS: Perfect Forward Secrecy - Cryptographic property for session key security
AES: Advanced Encryption Standard
RSA: Rivest-Shamir-Adleman - Public key cryptography
ECDSA: Elliptic Curve Digital Signature Algorithm
SHA: Secure Hash Algorithm
X.509: Certificate standard
CA: Certificate Authority
CSPRNG: Cryptographically Secure Pseudo-Random Number Generator

Database Terms

MySQL: Open-source relational database
PostgreSQL: Open-source object-relational database
TDE: Transparent Data Encryption
RBAC: Role-Based Access Control

Document Version: 1.0 Date: 2025-11-29 Prepared for: ANSSI R226 Authorization Application Document Classification: Regulatory Compliance - Confidential

1. DETAILED TECHNICAL SPECIFICATIONS​

1.1 Commercial Technical Datasheet​

Core Capabilities​

1.2 Interception Capabilities​

1.2.1 Message Acquisition​

1.2.2 Data Processing Capabilities​

1.2.3 Analysis Capabilities​

1.3 Countermeasure Capabilities​

1.3.1 Privacy Protection Mechanisms​

1.3.2 Data Protection Features​

1.4 Storage Architecture: Mnesia + SQL Two-Tier Design​

Overview​

Tier 1: Mnesia In-Memory Message Queue​

Tier 2: SQL Database for CDR Export/Archival​

Architecture Diagram​

Lawful Interception Implications​

1.5 Multi-Protocol Frontend Integration Architecture​

Architecture Overview​

Frontend Protocol Integration Details​

Unified Interception Across All Protocols​

1.6 Technical Architecture for Lawful Interception​

Lawful Interception Integration Points​

ETSI Lawful Interception Standard Interfaces​

Interception Triggering Mechanisms​

2. ENCRYPTION AND CRYPTANALYSIS CAPABILITIES​

2.1 Cryptographic Capabilities Overview​

2.2 Transport Layer Encryption​

2.2.1 TLS/SSL Implementation​

2.3 Data Encryption at Rest​

2.3.1 Database Encryption​

2.3.2 Mnesia Disc Storage​

2.3.3 File System Encryption​

2.4 Authentication and Access Control​

2.4.1 API Authentication​

2.4.2 Database Authentication​

2.5 Cryptographic Algorithm Details​

2.5.1 Hashing Algorithms​

2.5.2 Symmetric Encryption​

2.5.3 Asymmetric Encryption​

2.6 SMS Protocol Security​

2.6.1 SMS Message Encoding​

2.6.2 Protocol Security Considerations​

2.7 Cryptanalysis and Security Assessment Capabilities​

2.7.1 Protocol Analysis Tools​

2.7.2 Vulnerability Assessment Considerations​

2.8 Key Management Infrastructure​

2.8.1 Key Generation​

2.8.2 Key Storage and Protection​

2.8.3 Key Distribution​

2.9 Compliance and Standards​

2.10 Cryptanalysis Resistance​

2.10.1 Design Principles​

2.10.2 Operational Security​

3. INTERCEPTION CONTROL AND AUTHORIZATION​

3.1 Access Control for Lawful Interception​

3.2 Data Retention and Privacy​

3.3 Handover Interfaces for Law Enforcement​

4. SYSTEM SECURITY AND INTEGRITY​

4.1 Application Security​

4.2 Network Security​

4.3 Monitoring and Intrusion Detection​

4.4 High Availability and Disaster Recovery​

5. DOCUMENTATION REFERENCES​

5.1 Technical Manuals​

5.2 Security Certifications​

5.3 Compliance Documentation​

6. CONTACT INFORMATION​

APPENDICES​

Appendix A: SMS Message Flow with Interception Points​

A.1 Outbound SMS Flow (Mobile Terminated)​

A.2 Inbound SMS Flow (Mobile Originated)​

Appendix B: CDR Schema for Lawful Interception​

B.1 Key CDR Fields for Lawful Interception​

B.2 CDR Query Examples for Lawful Interception​

B.3 CDR Database Access Methods​

B.4 CDR Retention and Privacy​

Appendix C: REST API Reference for Interception​

C.1 Message Retrieval Endpoints​

C.2 Filtering and Search​

Appendix D: Configuration Examples​

1. DETAILED TECHNICAL SPECIFICATIONS

1.1 Commercial Technical Datasheet

Core Capabilities

1.2 Interception Capabilities

1.2.1 Message Acquisition

1.2.2 Data Processing Capabilities

1.2.3 Analysis Capabilities

1.3 Countermeasure Capabilities

1.3.1 Privacy Protection Mechanisms

1.3.2 Data Protection Features

1.4 Storage Architecture: Mnesia + SQL Two-Tier Design

Overview

Tier 1: Mnesia In-Memory Message Queue

Tier 2: SQL Database for CDR Export/Archival

Architecture Diagram

Lawful Interception Implications

1.5 Multi-Protocol Frontend Integration Architecture

Architecture Overview

Frontend Protocol Integration Details

Unified Interception Across All Protocols

1.6 Technical Architecture for Lawful Interception

Lawful Interception Integration Points

ETSI Lawful Interception Standard Interfaces

Interception Triggering Mechanisms

2. ENCRYPTION AND CRYPTANALYSIS CAPABILITIES

2.1 Cryptographic Capabilities Overview

2.2 Transport Layer Encryption

2.2.1 TLS/SSL Implementation

2.3 Data Encryption at Rest

2.3.1 Database Encryption

2.3.2 Mnesia Disc Storage

2.3.3 File System Encryption

2.4 Authentication and Access Control

2.4.1 API Authentication

2.4.2 Database Authentication

2.5 Cryptographic Algorithm Details

2.5.1 Hashing Algorithms

2.5.2 Symmetric Encryption

2.5.3 Asymmetric Encryption

2.6 SMS Protocol Security

2.6.1 SMS Message Encoding

2.6.2 Protocol Security Considerations

2.7 Cryptanalysis and Security Assessment Capabilities

2.7.1 Protocol Analysis Tools

2.7.2 Vulnerability Assessment Considerations

2.8 Key Management Infrastructure

2.8.1 Key Generation

2.8.2 Key Storage and Protection

2.8.3 Key Distribution

2.9 Compliance and Standards

2.10 Cryptanalysis Resistance

2.10.1 Design Principles

2.10.2 Operational Security

3. INTERCEPTION CONTROL AND AUTHORIZATION

3.1 Access Control for Lawful Interception

3.2 Data Retention and Privacy

3.3 Handover Interfaces for Law Enforcement

4. SYSTEM SECURITY AND INTEGRITY

4.1 Application Security

4.2 Network Security

4.3 Monitoring and Intrusion Detection

4.4 High Availability and Disaster Recovery

5. DOCUMENTATION REFERENCES

5.1 Technical Manuals

5.2 Security Certifications

5.3 Compliance Documentation

6. CONTACT INFORMATION

APPENDICES

Appendix A: SMS Message Flow with Interception Points

A.1 Outbound SMS Flow (Mobile Terminated)

A.2 Inbound SMS Flow (Mobile Originated)

Appendix B: CDR Schema for Lawful Interception

B.1 Key CDR Fields for Lawful Interception

B.2 CDR Query Examples for Lawful Interception

B.3 CDR Database Access Methods

B.4 CDR Retention and Privacy

Appendix C: REST API Reference for Interception

C.1 Message Retrieval Endpoints

C.2 Filtering and Search

Appendix D: Configuration Examples