Solution Principles
Technical Architecture & Encryption Design
Our VoLTE End-to-End Encryption solution delivers carrier-grade secure voice communication over standard 4G/5G networks. By embedding encryption directly into the Modem firmware layer, we achieve transparent, network-independent protection for voice calls — without requiring any modifications to the operator’s infrastructure.
Key Technologies
Modem-Layer Customization
The Modem (baseband chip) on the phone side is where VoLTE functionality is implemented. VoLTE is essentially IMS-based VoIP calling — all interactions with the network layer, including LTE attachment, IMS registration, SIP signaling transception, and RTP voice stream encoding/decoding, are handled by the protocol stack within the Modem.
The encryption module is typically inserted as a middleware layer within the Modem protocol stack — performing AES-256 encryption on AMR voice before RTP packetization. These deep customizations are all implemented at the Modem firmware layer.
Unisoc SOC provides RIL (Radio Interface Layer) extensions that enable the AP to process RTP payloads. The AP layer uses this interface to manipulate the RTP stream, implementing the delivery of encrypted digital envelopes and the encryption/decryption of AMR voice packets.
Session Key Distribution
The session key PCK is randomly generated by the caller and encapsulated in an IMessage structure sent to the callee. The IMessage structure is delivered within the first few voice packets after the session is established (this is why there is approximately 0.3 seconds of noise after call setup).
Both parties use the SAKKE algorithm to encrypt/decrypt the PCK, and the ECCSI algorithm to sign and verify the IMessage (see the Algorithm Principles section for details).
User Private Key Generation and Distribution
The user’s IBE private key is generated by the KMS based on the user’s communication number, and is uniquely determined by the KMS root key and the user’s communication number. The PKG (Private Key Generator) uses the SAKKE/ECCSI algorithm.
Technical Advantages
Strong Network Adaptability
Any activated SIM card capable of standard VoLTE/VoNR calling works with our phone for encrypted voice calls.
Because all modifications occur in the user plane (voice packets), the network provider transparently passes them through without awareness and requires no modifications from the network provider.
Lighter, More Secure, More Reliable, More Cost-Effective
By using IBE-based elliptic curve algorithms (SAKKE/ECCSI), the KMS does not need to participate in the encrypted call establishment process.
More lightweight (no need to deploy and maintain an online KMS platform), more secure (KMS is isolated and cannot be attacked online), and more reliable (no KMS single point of failure).
Key System
Key Generation and Usage
Step 1: KMS Initialization Process
As shown in the figure, insert the U-Key and boot to launch KMS initialization. Enter the organization name, and the KMS will establish an exclusive encryption domain and randomly generate its encryption root key pair (Z_T (S) private key, Z_T (P) public key) and signature root key pair (KSAK private key, KPAK public key).
U-Key hardware encryption is adopted by KMS to realize secure storage of root keys.
Step 2: KMS Generate Per-Terminal Private Keys
As shown in the figure, input the mobile phone’s VoLTE number into KMS. KMS calculates RSK with the number and Z_T (S), and SSK with the number and KSAK. All terminal keys and encryption parameters (Z_T (P), RSK, KPAK, SSK) are encapsulated into a QR code for key download through KMC scanning.
Step 3: Terminal Scan QR Code
As shown in the figure, successful QR code loading via KMC generates the corresponding certificate record. KMC invokes the TEE interface for secure storage of encryption keys.
Step 4: Make a VoLTE Encryption Call
Initiation of Encrypted Call by the Calling Party:
When initiating an encrypted call, the calling party randomly generates a primary session key (PCK). It encrypts the PCK via the SAKKE algorithm using the peer’s phone number and the KMS encryption root public key to obtain encrypted PCK.
The calling party constructs a digital envelope (containing communication metadata, symmetric encryption algorithm identifier and encrypted PCK), signs the digital envelope with its own user signature private key adopting the ECCSI algorithm, and outputs the final signed digital envelope embedded with encrypted PCK.
Transmission of the Digital Envelope:
After the VoLTE voice call channel is established, the digital envelope is transmitted inside the voice RTP Payload. The VoLTE network transparently forwards the voice payload to the called terminal without any parsing or modification.
The calling party transmits the digital envelope periodically until receiving an acknowledgment from the called party or reaching the transmission timeout threshold.
Verification and Decryption of the Digital Envelope:
Upon receiving the digital envelope, the called party verifies the envelope signature with the caller’s phone number and the KMS signature root public key (ECCSI algorithm). Afterwards, it decrypts the PCK with its local encryption private key via the SAKKE algorithm.
The called party sends an acknowledgment message to the calling party over RTP Payload to stop the periodic retransmission from the caller.
Secure Call Establishment:
If all steps 4 to 6 complete without errors, both communication parties derive working session keys (256-bit length) from PCK, and perform encryption and decryption for voice packets with the AES-256-CTR algorithm.
References
| No. | Document | Title | URL | Role |
|---|---|---|---|---|
| [1] | RFC 6507 | Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) | tools.ietf.org/html/rfc6507 | Signature |
| [2] | RFC 6508 | Sakai-Kasahara Key Encryption (SAKKE) | tools.ietf.org/html/rfc6508 | Encryption |
| [3] | RFC 6509 | Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package | tools.ietf.org/html/rfc6509 | Key Package |
| [4] | RFC 3830 | MIKEY: Multimedia Internet KEYing | tools.ietf.org/html/rfc3830 | Key Exchange |
| [5] | RFC 3711 | The Secure Real-time Transport Protocol (SRTP) | tools.ietf.org/html/rfc3711 | Transport Security |
| [6] | FIPS 197 | Advanced Encryption Standard (AES) | nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf | Symmetric Encryption |
| [7] | TS 33.180 | Security of the Mission Critical Service (3GPP) | 3gpp.org/dynareport/33180.htm | MCX Security Framework |