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 OmniCSCF IMS Core Network (Call Session Control Functions).

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 System Identification

Product Name: OmniCSCF IMS Core Network Product Type: IP Multimedia Subsystem (IMS) Core Network Primary Function: VoIP/VoLTE call session control and multimedia service delivery Deployment Model: On-premises telecommunications infrastructure

Network Components:

• P-CSCF (Proxy Call Session Control Function)
• E-CSCF (Emergency Call Session Control Function)
• I-CSCF (Interrogating Call Session Control Function)
• S-CSCF (Serving Call Session Control Function)

This system handles registration, authentication, session routing, and call control for IP Multimedia Subsystem (IMS) networks. The detailed interception capabilities and encryption characteristics are described in the sections below.

1.2 Interception Capabilities

1.2.1 Registration and Session Acquisition

SIP Registration Capture:

The CSCF system processes all SIP registrations and maintains complete registration state:

• User Identifiers:

  • IMPU (IP Multimedia Public Identity) - SIP URI (e.g., sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org)
  • IMPI (IP Multimedia Private Identity) - Authentication username (e.g., user@ims.mnc001.mcc001.3gppnetwork.org)
  • IMSI (International Mobile Subscriber Identity) - From P-headers or HSS
  • MSISDN (Mobile phone number) - From IMPU or HSS user profile

• Registration Metadata:

  • Contact URI (actual UE network address)
  • Path header (route back through P-CSCF)
  • Service-Route header (route to S-CSCF)
  • User-Agent string (device type identification)
  • Registration expiry timestamp
  • Source IP address and port
  • Transport protocol (TCP/UDP/TLS)
  • Authentication vectors (RAND, AUTN, XRES, CK, IK from HSS)

• Network Location Information:

  • P-Access-Network-Info header (cell tower, location area)
  • P-Visited-Network-ID (roaming network identification)
  • Received IP address (actual source)
  • P-CSCF address (network entry point)

Call Session Capture:

The S-CSCF maintains complete SIP dialog state for all active calls:

• Session Identifiers:

  • Call-ID (unique session identifier)
  • From/To URIs and tags
  • Route sets for both parties
  • Original-Dialog-ID (for Application Server interaction tracking)

• Session Metadata:

  • Caller identity (From header, P-Asserted-Identity)
  • Called party (To header, Request-URI)
  • Session establishment timestamp
  • Session termination timestamp
  • Dialog state (Early/Confirmed/Deleted)
  • CSeq numbers (transaction sequencing)

• Media Information:

  • SDP (Session Description Protocol) in SIP message bodies
  • Media server addresses (OmniTAS)
  • Codec information (audio/video formats)
  • Media flow endpoints
  • RTP/RTCP port allocations

Emergency Call Identification:

The E-CSCF component identifies and routes emergency calls:

• Emergency number detection (112, 911, etc.)
• IMEI (International Mobile Equipment Identity) capture
• IMEI to MSISDN mapping (for callback)
• Location information from UE or network
• HELD (HTTP-Enabled Location Delivery) protocol support
• Emergency routing destination (PSAP/emergency AS)

1.2.2 Data Storage and Processing

IMPORTANT: In-Memory State Only

The CSCF components (P-CSCF, E-CSCF, I-CSCF, S-CSCF) maintain all state data in memory only. There is no persistent database storage of registration or call session data. All registration bindings, dialog state, and IPsec security associations are stored in-memory and are lost on system restart.

Active Registration Data (In-Memory):

The CSCF system maintains real-time state only:

P-CSCF Registration State:

• IPsec Security Association data (SPI pairs, ports, encryption parameters)
• UE contact bindings and network addresses
• IPsec tunnel endpoints and status
• Registration validity periods

S-CSCF Registration State:

• Public identities (IMPU) and current registration state
• Contact bindings with Path headers, User-Agent, received addresses
• Private identity (IMPI) to public identity mappings
• User profiles from HSS (cached during registration)

Active Session State (In-Memory):

The S-CSCF maintains active call state only:

• Call identifiers (Call-ID), participant identities (From/To tags)
• Route sets and contact addresses
• Session state (Early/Confirmed/Terminated)
• Session timing information

No CDR or Historical Tracking:

The CSCF components do not generate or store:

• Call Detail Records (CDRs)
• Historical call records
• Historical registration records
• Long-term event tracking

CDR Generation and Historical Tracking: All call detail records, charging data, and historical call tracking are handled by the TAS (Telephony Application Server - OmniTAS), not by the CSCF components.

SIP/Diameter Message Logging:

CSCFs can generate real-time event logs for operational purposes:

• SIP Message Logging: Optional logging of SIP messages (INVITE, REGISTER, etc.)
• Diameter Message Logging: Optional logging of Diameter transactions (Cx, Rx, Ro)
• System Events: Configuration changes, errors, failures

These logs are transient operational logs, not persistent call records. Log retention is configurable and typically short-term (hours to days) for debugging purposes only.

1.2.3 Analysis Capabilities

Real-Time Monitoring:

The Phoenix LiveView web control panel provides:

• Registration Monitoring:

  • View all registered users with pagination
  • Search by IMPU, contact, IMPI
  • Registration details (contact, path, user-agent, expiry)
  • Forced de-registration capability

• Dialog Monitoring:

  • Active call sessions view
  • Call-ID, From/To URIs, state, duration
  • Call termination capability (send BYE)
  • Auto-refresh every 5 seconds

• System Status:

  • Diameter peer status (HSS, PCRF, OCS connectivity)
  • Frontend gateway status
  • System capacity metrics
  • IPsec tunnel capacity (P-CSCF)

Note on Historical Data:

The CSCF components do not maintain historical data. For historical call records, CDRs, and communication pattern analysis, lawful interception authorities must coordinate with OmniTAS (Telephony Application Server), which handles all CDR generation and long-term call tracking.

Real-Time Service Triggering Visibility:

The S-CSCF processes Initial Filter Criteria (iFC) in real-time:

• iFC evaluation determines which Application Servers are triggered for each call
• Real-time visibility into which services are invoked
• Application Server routing decisions visible in SIP message flow

Network Status:

• HSS connectivity status (Diameter Cx interface)
• S-CSCF selection distribution (I-CSCF)
• Call routing patterns
• Application Server response times
• Diameter transaction performance

1.3 Countermeasure Capabilities

1.3.1 Privacy Protection Mechanisms

Communication Confidentiality:

• IPsec Tunnels: ESP (Encapsulating Security Payload) tunnels between UE and P-CSCF

  • Encryption: AES-CBC, AES-GCM
  • Authentication: HMAC-SHA1, HMAC-SHA256
  • Key derivation from IMS AKA (CK/IK from HSS)
  • Per-UE security associations

• TLS/TLS Support:

  • SIP over TLS (SIPS) support
  • Diameter over TLS (HSS, PCRF, OCS connections)
  • Certificate-based authentication
  • Perfect Forward Secrecy (PFS) via ECDHE/DHE

• SIP Privacy Headers:

  • P-Asserted-Identity (authenticated caller ID)
  • Privacy header (request caller ID suppression)
  • Anonymous session support

Access Control:

• Web UI authentication and access control
• BINRPC interface for control panel (port 2046)
• Registry access controls and role separation
• SIP authentication (AKA via HSS)
• Diameter peer authentication

Audit Logging:

• Comprehensive SIP and Diameter message logging
• Registration/de-registration events
• Call establishment and termination events
• Administrative actions via web UI
• Configuration changes
• Authentication success/failure

1.3.2 Data Protection Features

Access Security:

• Role-based access control (RBAC)
• Read-only monitoring accounts
• Authentication and authorization controls

System Hardening:

• Minimal exposed network ports (5060 SIP, 3868 Diameter, 8086 Web UI)
• SIP message sanity checking
• Max-Forwards loop prevention
• Rate limiting and anti-flood protection
• Message size limits
• Worker process isolation

1.4 Lawful Interception Integration Points

1.5.1 ETSI Lawful Interception Architecture

The CSCF system provides foundation for ETSI-compliant lawful interception. While native X1/X2/X3 interfaces are not built-in, all necessary data access points exist for integration with external Lawful Interception Mediation Function (LIMF) systems.

Standard ETSI LI Interfaces:

X1 Interface - Administration Function:

• Purpose: Warrant and target provisioning from law enforcement
• Direction: LEMF → LIMF (bidirectional)
• Functions:
  • Activate/deactivate interception for targets (IMPUs, IMSIs, MSISDNs)
  • Set interception duration and validity period
  • Configure filtering criteria (identities, time windows)
  • Retrieve interception status
• Integration with CSCF:
  • LIMF maintains warrant database (target list - external to CSCF)
  • LIMF monitors CSCF real-time state and message logs for matching sessions
  • LIMF filters based on X1 provisioned criteria

X2 Interface - IRI (Intercept Related Information) Delivery:

• Purpose: Deliver session metadata to law enforcement
• Direction: LIMF → LEMF (one-way)
• Data Format: ETSI TS 102 232 compliant XML/ASN.1
• Content from CSCF:
  • Session identifiers (Call-ID, dialog tags)
  • Calling party (From URI, P-Asserted-Identity, IMPU, IMSI, MSISDN)
  • Called party (To URI, Request-URI, IMPU, IMSI, MSISDN)
  • Registration timestamps
  • Session setup/teardown timestamps
  • Network location (P-Access-Network-Info, cell tower, location area)
  • P-CSCF/S-CSCF addresses (network element identification)
  • User-Agent (device type)
  • Roaming information (P-Visited-Network-ID)

X3 Interface - CC (Content of Communication) Delivery:

• Purpose: Deliver actual communication content
• Direction: LIMF → LEMF (one-way)
• Data Format: ETSI TS 102 232 compliant
• Content from CSCF:
  • SIP message bodies (SDP session descriptions)
  • Media server addresses (for RTP interception)
  • Codec information
  • SIP MESSAGE instant messages (body content)
  • Application data (if routed through CSCF)

Note: For voice/video RTP streams, the LIMF must also integrate with media servers (OmniTAS) to capture actual media content. The CSCF provides session setup information (SDP) showing where media flows.

1.5.2 CSCF Data Sources for Lawful Interception

1. Registration Data Access:

P-CSCF Registration Data:

• IMPU (public identity)
• Contact URI (UE network address)
• Received IP and port
• Path header
• Registration expiry
• IPsec SPI and port information
• User-Agent string

S-CSCF Registration Data:

• Public identities (IMPU), barring status, registration state
• Contact bindings with Path headers, User-Agent, received addresses
• Private identity (IMPI) to public identity mappings
• User profiles from HSS (XML format including subscriber details)

Access Methods:

• Read-only data access interfaces
• Web UI monitoring interface
• Real-time event logging

2. Active Session Data:

S-CSCF Dialog Data:

• Call-ID (unique session identifier)
• From/To URIs and tags
• Caller and callee CSeq numbers
• Route sets for both parties
• Contact addresses
• Dialog state (Early, Confirmed, Deleted)
• Start timestamp
• Timeout values

Access Methods:

• Real-time dialog state monitoring
• Query by session identifiers or party identifiers
• Export capabilities for forensic analysis

3. SIP Message Logging:

Log Capture:

• All SIP messages can be logged (REGISTER, INVITE, MESSAGE, etc.)
• Configurable log levels
• Structured logging with timestamps
• Syslog or file-based logging

Log Analysis:

• Parse SIP headers for identity extraction
• Extract SDP for media information
• Track message sequences (CSeq)
• Correlate requests and responses

Example Log Entry:

INFO: INVITE sip:+33687654321@ims.mnc001.mcc001.3gppnetwork.org SIP/2.0
From: <sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org>;tag=abc123
To: <sip:+33687654321@ims.mnc001.mcc001.3gppnetwork.org>
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@ims.mnc001.mcc001.3gppnetwork.org
P-Asserted-Identity: <sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org>
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=208011234567890
Content-Type: application/sdp

v=0
o=- 1234567890 1234567890 IN IP4 192.168.1.100
s=-
c=IN IP4 10.20.30.40
t=0 0
m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

4. Diameter Message Logging:

Cx Messages (HSS Communication):

• UAR/UAA: User authorization (contains IMPU, IMPI)
• LIR/LIA: Location information (contains IMPU, serving S-CSCF)
• MAR/MAA: Authentication (contains IMPI, authentication vectors)
• SAR/SAA: Server assignment (contains IMPU, IMPI, user profile XML)

Diameter Data Available:

• IMSI (from user profile)
• MSISDN (from user profile)
• Associated IMPUs (multiple identities per subscriber)
• User profile (services, barring, roaming status)

Log Example:

Diameter Cx SAA received from HSS:
User-Name: user@ims.mnc001.mcc001.3gppnetwork.org
Public-Identity: sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org
Server-Name: sip:scscf.ims.mnc001.mcc001.3gppnetwork.org
Result-Code: 2001 (Success)
User-Data: <XML user profile with IMSI, MSISDN, iFC>

5. Emergency Call Data (E-CSCF):

IMEI to MSISDN Mapping:

• P-CSCF creates mapping when UE registers with IMEI
• 24-hour TTL (Time-To-Live)
• Used for emergency callback
• Synchronized across P-CSCF cluster nodes

Data Retention:

• IMEI to MSISDN mappings retained for 24 hours
• Available for emergency callback correlation
• Accessible via monitoring interfaces

Emergency Call Logs:

• Emergency number detection (112, 911, etc.)
• IMEI extraction from contact or P-headers
• Location information (from HELD or P-Access-Network-Info)
• PSAP (Public Safety Answering Point) routing
• E-CSCF to emergency AS routing

1.5.3 Integration Capabilities for LIMF

The system provides multiple integration methods for Lawful Interception Mediation Function (LIMF) systems:

1. Registration and Session Data Access:

   • Real-time access to registration data (identities, locations, device information)
   • Active session monitoring (call state, participants, timing)
   • Historical query capabilities

2. Event Logging:

   • SIP message logging with configurable detail levels
   • Diameter message logging for HSS interactions
   • Structured event logs with timestamps

3. Real-Time Monitoring:

   • Live registration status monitoring
   • Active call session tracking
   • Emergency call detection and routing information

Integration methods support both polling-based and event-driven architectures for LIMF connectivity.

1.5.4 CSCF Data Mapping to LI Interfaces

CSCF Data to IRI (X2) Mapping:

CSCF Data Source	IRI Field	Data Example
IMPU (SIP headers/in-memory state)	Party A	sip:+33612345678@ims.mnc001.mcc001.3gppnetwork.org
IMPI (SIP headers/in-memory state)	Authentication ID	user@ims.mnc001.mcc001.3gppnetwork.org
IMSI (HSS user profile)	Subscriber ID	208011234567890
MSISDN (HSS user profile)	Phone Number	+33612345678
Call-ID (SIP headers/dialog state)	Session ID	f81d4fae-7dec-11d0-a765-00a0c91e6bf6@...
From/To (SIP headers)	Party A/Party B	sip:+33612345678@... / sip:+33687654321@...
Registration timestamp (in-memory)	Event Time	2025-11-29T10:30:00Z
P-Access-Network-Info (SIP header)	Location	3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=208011234567890
Received IP (SIP contact)	UE IP Address	10.20.30.40:5060
P-CSCF address (SIP routing)	Network Element	10.4.12.165:5060
S-CSCF address (SIP routing)	Network Element	10.4.11.45:5060

CSCF Data to CC (X3) Mapping:

CSCF Data Source	CC Field	Data Example
SIP MESSAGE body	Instant Message Content	"Hello, how are you?"
SDP in INVITE	Media Session Info	RTP endpoints, codecs
Media server address	RTP Interception Target	10.50.60.70:49170

Note: For actual voice/video content (RTP), the LIMF must coordinate with media servers (OmniTAS) to capture RTP streams. CSCF provides session setup information only.

1.5 Web-Based Monitoring Interface

The system includes a web-based control panel for real-time monitoring and administrative access:

Monitoring Capabilities:

• Real-time registration status (active subscribers, locations, device information)
• Active call session monitoring (participants, call state, timing)
• Search and filtering by identity (IMPU, IMPI, IMSI, MSISDN)
• IPsec tunnel status and capacity monitoring
• Export capabilities for forensic analysis

Security:

• HTTPS/TLS encrypted access
• Authentication required
• Audit logging of all administrative actions
• Read-only access modes for monitoring personnel

---

2. ENCRYPTION AND CRYPTANALYSIS CAPABILITIES

2.1 Cryptographic Capabilities Overview

The OmniCSCF implements multiple layers of cryptographic protection for signaling and subscriber data. This section documents all cryptographic capabilities as required by ANSSI.

2.2 IPsec ESP Tunnel Encryption (UE to P-CSCF)

2.2.1 IPsec Protocol Implementation

Supported IPsec Mode:

• ESP (Encapsulating Security Payload) - IP Protocol 50
• Transport mode (not tunnel mode)
• Protects SIP signaling between UE and P-CSCF

Encryption Algorithms Supported:

The system with kernel IPsec supports:

• AES-CBC (Advanced Encryption Standard - Cipher Block Chaining):

  • AES-128-CBC (128-bit key)
  • AES-192-CBC (192-bit key)
  • AES-256-CBC (256-bit key) - Recommended

• AES-GCM (Advanced Encryption Standard - Galois/Counter Mode):

  • AES-128-GCM (128-bit key with AEAD)
  • AES-256-GCM (256-bit key with AEAD) - Recommended

• 3DES-CBC (Triple DES - Cipher Block Chaining):

  • 168-bit effective key (deprecated, legacy compatibility)

• NULL Encryption:

  • No confidentiality (authentication only)
  • Used only for debugging or specific compliance scenarios

Authentication Algorithms Supported:

• HMAC-SHA1 (Hash-based Message Authentication Code - SHA-1):

  • 160-bit output
  • Legacy compatibility

• HMAC-SHA256 (HMAC - SHA-256):

  • 256-bit output
  • Recommended

• HMAC-SHA384 (HMAC - SHA-384):

  • 384-bit output

• HMAC-SHA512 (HMAC - SHA-512):

  • 512-bit output

• HMAC-MD5:

  • 128-bit output
  • Deprecated, legacy compatibility only

Key Derivation:

IPsec keys (CK - Cipher Key, IK - Integrity Key) are derived from IMS AKA authentication:

1. UE performs AKA authentication with S-CSCF/HSS
2. HSS generates CK (128-bit) and IK (128-bit)
3. S-CSCF delivers CK/IK to P-CSCF via internal interface
4. P-CSCF uses CK/IK to establish IPsec security associations with UE
5. CK used for ESP encryption
6. IK used for ESP authentication

Security Association Parameters:

• Lifetime: Tied to SIP registration expiry (typically 599 seconds)
• Replay Protection: Enabled (anti-replay window)
• Sequence Numbers: 32-bit or 64-bit (ESN - Extended Sequence Numbers)
• Perfect Forward Secrecy: Not applicable (keys from AKA, not Diffie-Hellman)

Implementation:

The P-CSCF IPsec capability:

• Interfaces with Linux kernel IPsec stack (XFRM framework)
• Configures security policies and associations via kernel API
• SPI (Security Parameter Index) allocation and management
• Port allocation for protected traffic

2.2.2 IPsec Configuration Capabilities

Cipher Suite Selection:

The P-CSCF can be configured to prefer specific cipher suites:

Preferred (strong security):

• ESP with AES-256-GCM and HMAC-SHA256
• ESP with AES-256-CBC and HMAC-SHA256

Supported (compatibility):

• ESP with AES-128-CBC and HMAC-SHA1
• ESP with 3DES-CBC and HMAC-SHA1 (legacy)

Key Management:

• IKE (Internet Key Exchange) is NOT used
• Keys provided via IMS AKA (CK/IK from HSS)
• Manual security association setup via kernel XFRM
• Automatic SA teardown on registration expiry

Tunnel Lifecycle:

1. UE registers → AKA authentication → CK/IK generated
2. P-CSCF receives CK/IK from S-CSCF
3. P-CSCF allocates SPI pair (client SPI, server SPI)
4. P-CSCF allocates port pair (client port, server port)
5. P-CSCF configures kernel IPsec SAs using CK/IK
6. P-CSCF sends IPsec parameters to UE in 200 OK (Security-Server header)
7. UE configures IPsec SAs with same parameters
8. All subsequent SIP traffic flows through ESP tunnels
9. On registration expiry or de-registration: SAs deleted, resources freed

2.3 TLS Encryption (SIP and Diameter)

2.3.1 TLS for SIP (SIPS)

Supported TLS Versions:

• TLS 1.2 (RFC 5246) - Supported
• TLS 1.3 (RFC 8446) - Supported (if kernel/library support)
• TLS 1.0/1.1 - Deprecated (disabled by default)
• SSL 2.0/3.0 - NOT SUPPORTED (known vulnerabilities)

TLS Implementation:

the system uses OpenSSL or LibreSSL:

• Industry-standard TLS libraries
• Cryptographically validated implementations
• Regular security updates

Cipher Suites Supported:

TLS 1.3 (Preferred):

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• TLS_CHACHA20_POLY1305_SHA256

TLS 1.2 (Supported):

• ECDHE-RSA-AES256-GCM-SHA384 (Perfect Forward Secrecy)
• ECDHE-RSA-AES128-GCM-SHA256 (Perfect Forward Secrecy)
• ECDHE-ECDSA-AES256-GCM-SHA384 (Perfect Forward Secrecy)
• DHE-RSA-AES256-GCM-SHA384 (Perfect Forward Secrecy)
• DHE-RSA-AES128-GCM-SHA256 (Perfect Forward Secrecy)

Weak ciphers disabled:

• No RC4
• No MD5
• No NULL encryption
• No EXPORT-grade ciphers
• No DES/3DES (deprecated)

Certificate Support:

• X.509 certificates (standard format)
• RSA keys: 2048-bit minimum, 4096-bit recommended
• ECDSA keys: P-256, P-384, P-521 curves supported
• Certificate chain validation
• CRL (Certificate Revocation List) checking (optional)
• OCSP (Online Certificate Status Protocol) (optional)

TLS Features:

• Perfect Forward Secrecy (PFS): Via ECDHE/DHE key exchange
• Server Name Indication (SNI): Supported
• TLS Session Resumption: Supported (performance optimization)
• Client Certificate Authentication: Supported (mutual TLS)

SIP over TLS (SIPS):

• Transport: TCP with TLS encryption
• Port: 5061 (standard SIPS port)
• Used for inter-CSCF communication (optional)
• Used for trusted network connections

2.3.2 TLS for Diameter

Diameter Capabilities:

The system supports:

• Diameter over SCTP (preferred for reliability)
• Diameter over TCP with TLS
• Port: 3868 (standard Diameter port)

Use Cases:

• Cx interface: S-CSCF/I-CSCF to HSS (subscriber data, authentication)
• Rx interface: P-CSCF to PCRF (QoS policy)
• Ro interface: S-CSCF to OCS (online charging - if enabled)

TLS Configuration for Diameter:

Same cipher suites as SIP

• TLS 1.2/1.3
• ECDHE/DHE key exchange (PFS)
• AES-GCM encryption
• SHA256/SHA384 authentication

Certificate-Based Authentication:

• Diameter peers authenticate via TLS certificates
• Mutual TLS (both client and server certificates)
• FQDN (Fully Qualified Domain Name) validation in certificates
• Trusted CA chain validation

2.4 Authentication Cryptography

2.4.1 IMS AKA Cryptographic Functions

3GPP AKA Algorithm (MILENAGE):

Used for generating authentication vectors (RAND, AUTN, XRES, CK, IK):

Cryptographic Functions:

• f1: Message authentication function (compute MAC-A and MAC-S)
• f2: Response function (compute RES from RAND and K)
• f3: Cipher key derivation (compute CK)
• f4: Integrity key derivation (compute IK)
• f5: Anonymity key function (compute AK for IMSI privacy)

Key Material:

• K: 128-bit permanent subscriber key (stored in ISIM and HSS)
• OPc: Operator variant key (derived from K and OP)
• RAND: 128-bit random challenge
• SQN: 48-bit sequence number (replay protection)

AKA Sequence:

1. HSS generates RAND (cryptographically random)
2. HSS computes MAC-A = f1(K, RAND, SQN, AMF)
3. HSS computes AUTN = (SQN ⊕ AK) || AMF || MAC-A
4. HSS computes XRES = f2(K, RAND)
5. HSS computes CK = f3(K, RAND)
6. HSS computes IK = f4(K, RAND)
7. HSS sends {RAND, AUTN, XRES, CK, IK} to S-CSCF
8. S-CSCF challenges UE with RAND and AUTN
9. UE computes RES = f2(K, RAND) using ISIM
10. UE sends RES to S-CSCF
11. S-CSCF compares RES with XRES (authentication validation)

Security Properties:

• Mutual Authentication: UE verifies HSS via AUTN, HSS verifies UE via RES
• Key Freshness: RAND is random, SQN prevents replay
• Key Derivation: CK and IK derived from shared secret K

2.4.2 HTTP Digest Authentication

For non-IMS authentication (if used):

Algorithm: MD5 (RFC 2617)

• Hash Function: MD5 (128-bit output)
• Challenge-Response: Based on nonce
• Replay Protection: Nonce with timestamp

Note: HTTP Digest with MD5 is considered weak. IMS AKA is strongly preferred.

2.5 Hashing and Integrity

2.5.1 Hash Functions Available

the system can use (via OpenSSL/kernel crypto):

• SHA-256: 256-bit output, recommended
• SHA-384: 384-bit output
• SHA-512: 512-bit output
• SHA-1: 160-bit output, deprecated for security use
• MD5: 128-bit output, deprecated for security use

Usage:

• HMAC constructions for IPsec/TLS
• Data integrity verification
• Nonce generation
• Duplicate detection (Call-ID hashing)

2.5.2 Message Integrity

SIP Message Integrity:

• IPsec ESP: HMAC-SHA256 for authenticated SIP over IPsec
• TLS: Message authentication via TLS MAC
• SIP Digest: Authentication header integrity

Diameter Message Integrity:

• TLS: Diameter over TLS provides message authentication
• HMAC: Diameter messages can include HMAC AVPs for integrity

2.6 Random Number Generation

Cryptographically Secure Random Number Generation:

the system relies on:

• Linux kernel /dev/urandom: Cryptographically secure PRNG
• OpenSSL RAND_bytes(): CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)

Usage:

• SPI allocation (randomized starting value)
• Call-ID generation
• Branch parameter generation
• Nonce generation for authentication
• Session ID generation

2.7 Key Management

2.7.1 TLS Certificate Management

Certificate Storage:

• Filesystem storage with restricted permissions (0600)
• Located in: /etc/system/tls/
• PEM format for certificates and keys

Certificate Generation:

# Generate RSA 4096-bit private key
openssl genrsa -out system-key.pem 4096

# Generate CSR (Certificate Signing Request)
openssl req -new -key system-key.pem -out system.csr \
  -subj "/C=FR/ST=IDF/L=Paris/O=Omnitouch/CN=scscf.ims.mnc001.mcc001.3gppnetwork.org"

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

# Production: Submit CSR to trusted CA

Certificate Rotation:

• Annual certificate renewal recommended
• Graceful service restart to load new certificates
• No downtime required

2.7.2 IPsec Key Management

Key Derivation:

• CK (Cipher Key) and IK (Integrity Key) from IMS AKA
• 128-bit keys from HSS
• Delivered securely via Diameter Cx (over TLS)

Key Lifetime:

• Tied to SIP registration expiry (typically 599 seconds)
• Re-keying on registration refresh
• Automatic key destruction on de-registration

Key Storage:

• Ephemeral (in-memory only during active registration)
• Installed in kernel IPsec stack
• No persistent key storage
• Keys discarded when SA deleted

2.8 Cryptanalysis Resistance

2.8.1 Algorithm Selection

Defense Against Cryptanalysis:

• No custom algorithms: Only industry-standard, peer-reviewed algorithms
• Strong key sizes: AES-256, RSA-4096, SHA-256
• Authenticated encryption: AES-GCM (AEAD - Authenticated Encryption with Associated Data)
• Perfect Forward Secrecy: ECDHE/DHE in TLS
• Regular updates: OpenSSL/LibreSSL security patches applied

Deprecated Algorithms Disabled:

• MD5 (hash collisions)
• RC4 (stream cipher weaknesses)
• DES/3DES (small block size, key length)
• SSL 2.0/3.0 (protocol vulnerabilities)
• TLS 1.0/1.1 (BEAST, POODLE attacks)

2.8.2 Side-Channel Attack Mitigation

Timing Attack Resistance:

• Constant-time comparison for authentication responses
• No timing leaks in cryptographic operations (via OpenSSL)

Memory Protection:

• Kernel IPsec stack isolation
• Process memory isolation
• No swap for sensitive data (if configured)

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 203: 3GPP access security (IMS AKA)
• ETSI TS 133 210: IP network layer security (IPsec)
• 3GPP TS 33.203: Access security for IMS
• 3GPP TS 33.210: Network domain security

French Cryptography Regulations:

• No export-restricted cryptography (all standard algorithms)
• Standard cryptographic means (no government backdoors)
• ANSSI cryptographic product certification (if required)