FAQ

1. Strong adaptability — no need to modify existing IMS network configuration; works in any VoLTE network.
2. Short encrypted call setup time with high success rate — compared to other user-plane key exchange solutions, this solution uses the IBE algorithm suite, reducing public key interaction steps, shortening interaction latency, and improving success rate.
3. Lightweight — no need to deploy an online KMS platform.
4. Root key controlled by the end user — the root key, especially the signature root key, is in the hands of the end user, avoiding the security risk in other decentralized solutions where the trust root is controlled by the vendor.

Unisoc is a Chinese domestic mobile chipset platform that can provide us with more open customization interfaces.

Currently only voice and SMS encryption are supported; video encryption is not supported. The technical principle of video encryption is the same as voice, and it can be added in the future.

Not supported. These services involve transcoding, audio mixing, and callee number changes, making implementation very difficult.

Not currently supported. NM card encryption has been planned and is expected to be available in 2027.

Not currently supported. A wireless encryption gateway (containing 4-16 VoLTE modules with SIM cards) has been planned. VoLTE encrypted phones and the gateway support E2E encryption, and the gateway can connect to IP phones, IP-PBX gateways, and other wired communication networks via SIP. Expected to be available in 2027.

Yes, free online technical exchanges are supported but require an appointment. For on-site technical exchanges, a paid POC contract must be signed.

Yes, but additional contracts and fees are required.

One KMS and several phones. Bulk phone purchases qualify for discounts. For general use, the F70 is recommended. For outdoor scenarios requiring PTT services or explosion-proof environments, choose the D51.

Yes, they use the same technology and algorithms and are interoperable.

The deposit for test samples is calculated in accordance with the official website listed price. The buyer is responsible for all round-trip courier charges. The return shipping cost will be deducted from the deposit when we refund the deposit after receiving intact returned test units. All payments shall be completed via PayPal.

Contract Manufacturer: Qingdao Hisense Mobile Communication Technology Co., Ltd.
Cooperation Mode: Entrusted ODM by Cunmeng, core encryption IP belongs to Cunmeng
Delivery Term: FOB Qingdao | Payment: SWIFT T/T

The system enables VoLTE terminals to provide E2EE encryption in any IMS network without modifying the signaling layer. Key exchange occurs at the user plane (RTP payload). Traditional certificate-based methods are unsuitable: (1) certificates are too large, causing excessive packet splitting and affecting latency/success rate; (2) certificate exchange requires bidirectional confirmation, impossible in RTP protocol stack. MIKEY-SAKKE is the only optimal choice — it enables unidirectional key exchange. IMessage is split into 9-19 RTP packets (depending on AMR rate), sent in loops with 10s timeout, achieving ~200 packets across 10-20 rounds for high success rate.

Asymmetric Signatures: ECCSI (RFC 6507); Asymmetric Encryption: SAKKE (RFC 6508); Symmetric Encryption: AES 256 CTR (FIPS 197); Pairing for SAKKE: Tate-Lichtenbaum Pairing (RFC 6508, see Sakai et al. SCIS 2001); Random Generator: RAND_priv_bytes (from OpenSSL, secure random number generator). Test vectors: see respective RFC/FIPS standards.

Keys are generated using secure random numbers meeting SAKKE and ECCSI key order lengths. The function uses RAND_priv_bytes from OpenSSL-1.1.1u. In Android, OpenSSL's RAND_priv_bytes uses getrandom() to obtain entropy from kernel space via internal DRBG framework. The code generates 128-byte random data, converts to BIGNUM, and ensures the result is within [2, MIKEY_SAKKE_q - 1].

SAKKE keys: Z_T(S) root private encryption key = 1024 bit; Z_T(P) root public encryption key = 2048 bit; RSK user private encryption key = 2048 bit. ECCSI keys: KSAK root private signature key = 256 bit; KPAK root public signature key = 512 bit; SSK user private signature key = 256 bit. Session keys: PCK private call key = 128 bit; AES 256 key (derived from PCK) = 256 bit. IMessage signature length = 129 bytes (see RFC 6507).

KMS is a customized three-proof PAD (waterproof, dustproof, anti-fall) with a U-key. Security hardening: (1) Customized OS — all data ports (WiFi, USB, Bluetooth) closed; (2) MDM Kiosk mode — KMS APK always occupies screen; (3) Root key protected with U-Key — storage key encrypts root key, encrypted root key stored in U-Key. Not currently HSM, but can be customized as server version with PCIE encryption cards. Plans to support hard encryption cards on mobile devices (Nano/TF card form factor) next year.

KMS does not participate in encrypted sessions, so it does not need to be online. KMS supports backup by backing up encrypted root keys and storage keys to another blank U-KEY, then using that U-KEY to build a KMS backup on another PAD.

QR code scanning is used. KMS structures keys in binary format, encrypts them (using a fixed key defined in KMS and KMC source code), converts to QR codes. KMC scans the QR code, decrypts it, and extracts key information.

See Q5. KMS must insert the corresponding U-KEY to work. The U-KEY stores the encrypted root keys (Z_T(S) and KSAK), while the storage key (which decrypts them) is stored on KMS's disk.

See Q5. The KMS root key is encrypted and stored in U-KEY. The storage key is on KMS disk. Both KMS and U-KEY must be stolen to compromise root keys. KMS is offline and cannot be attacked online.

It supports using the same KMS for two VoLTE networks, provided both use the same parameters (e.g., AMR rate) to ensure no RTP-AMR transcoding occurs. Transcoding causes IMessage transmission failure.

User identity (VoLTE number) is a string, not an integer, unique within a KMS domain. VoLTE Client strips country codes (+xxx or 00xxx) and the first '0' from numbers to avoid interference. When entering numbers on KMS, country code and leading '0' should be omitted.

No. We do not modify the signaling plane of VoLTE. Hiding numbers is a function of the VoLTE system, not the encryption layer.

Trusted Execution Environment (TEE) is used to encrypt user's private keys before saving. TEE generates and saves the storage key (managed by TEE, KMC cannot obtain it). The TEE interface is used for encryption and decryption of user private keys.

See Q13. User private keys are encrypted via TEE. An attacker who steals the phone can only obtain encrypted private keys. To crack them, the attacker must breach the TEE.

Enter the user's ID in KMS and use KMC to scan the QR code again. The private key and global public key are exactly the same as before.

Currently not supported. The same key is used for the entire session.

GCM causes RTP payload to become longer, affecting compatibility with VoLTE networks (Packet loss may occur due to conflict with GBR — Guaranteed Bit Rate). AES-CTR preserves payload size.

Rand: random number generated by caller KMC, used for AES 256 key derivation (see Q19). Signature: ECCSI signature of the entire IMessage using signature keys (see Q4).

The AES 256 key is derived from a hash result with input Rand, PCK, and CSB ID from the IMessage. PCK is 128 bits; the derived AES key is 256 bits.

IMessage contains timestamp information. The receiver rejects encrypted calls where the IMessage timestamp differs from current time by more than 1 minute. Even if replay succeeds within the time gap, the attacker cannot decrypt PCK without the receiver's SAKKE private key, so they cannot encrypt/decrypt voice data.

KMS cannot revoke already-issued private keys; they can only be deleted on the KMC side. If terminal is lost: try MDM for remote erasure. Safest approach: abandon the VoLTE number and issue a new VoLTE number with new QR code.

Multiple parties may generate server-side mixing, causing IMessage to be undeliverable. Technically unfeasible.

KMC saves the latest 10 IMessage application and verification information, including the above content. Viewable directly in KMC's UI. More records can be customized if needed.

Not supporting PQC yet. Based on current quantum computer capabilities, MIKEY-SAKKE is temporarily secure but cannot guarantee resistance to future quantum attacks. Will follow PQC progress and upgrade after IBE algorithm (based on lattice for PQC) is released.

Yes, will show you.

Asymmetric encryption: algorithm replacement not supported. Symmetric encryption: will support an algorithm replacement framework where customers can replace their own S-BOX or the entire encryption algorithm.

Attacker can obtain the encrypted private key and global public key. Cracking the private key requires breaching TEE. If TEE is cracked, attacker can eavesdrop on all calls and impersonate the user (if VoLTE layer is also compromised). Solution: abandon the VoLTE number and issue a new one.

Through the SOC interface, the modem can modify some SOC parameters including VoLTE parameters. Which parameters can be modified depends on customer needs analysis.

The security level of SAKKE and ECCSI algorithms is 128. The security level is not 256. It was stated that the security level is basically equivalent to ECC256 (with about 128 security level).

See 3GPP TS 33.180 or RFC 3830. Step 1: Get SRTP Master key and Master Salt from IMessage (PCK is encrypted, Rand and CSB-ID are clear text; last parameter is fixed). Step 2: Get SRTP Session key and IV using AES_CM PRF function (RFC 3711), with output length 256 for SRTP Session key, replacing AEAD_AES_128_GCM with AES_256_CTR.

a) IMessage size is 488 Bytes. b) RTP payload size depends on AMR rate: full rate = 60 bytes, low rate = 30 bytes. 6 bytes of payload used as indicator (distinguishing IMessage vs AMR). Available bytes per packet reduced by 6. AMR sampling frequency = 50ms (20 packets/sec). At high AMR rate, 9 RTP packets (488/54=9) needed for one complete IMessage cycle.

Sender sends in cycles of up to 10 seconds (timeout timer). At high-speed AMR, can send 10*20/9 = 22 cycles maximum. As long as receiver gets at least one complete cycle, encrypted call is successfully established.

See Q31. AMR rate depends on network's IMS configuration. The phone supports mainstream AMR rates.

All random numbers are generated by RAND_priv_bytes, including root keys (encryption and signature) for KMS, and PCK and Rand for IMessage. Can also provide KMS/KMC based on HSM with physical random numbers (requires additional customization fees and hardware costs).

RAND_priv_bytes is provided by the OpenSSL library.

The security level is 128, basically the same as ECC256.

PCK is generated by RAND_priv_bytes. Used to derive SRTP master key and salt (see Q30). PCK is 128 bits as defined in TS 33.180 and RFC 6508 (named as SSV).

AES256 encrypts KMS root keys. The storage key encrypts root keys, is created randomly by KMS on first start, and is encrypted by a hardcoding key for storage in KMS. Encrypted KMS root keys stored in U-KEY. Storage key: 256-bit AES. Hardcoding key: different from KMC hardcoded key (used for QR code encryption).

Domain distinguishes a KMS business space. Example: KMS for Shanghai Public Security → domain 'ps.sh.cn'. One KMS can serve different communication systems (e.g., volte.ps.sh.cn and im.ps.sh.cn). KMS generates root keys per domain. One KMS can provide E2EE for different systems of different sectors. Current system only supports volte.xxx.xxx domain.

SSV (see RFC 6508) is the PCK, length 128 bits. Encrypted PCK(R,S) is 273 bytes in IMessage. SAKKE encryption: input M(PCK) = 16 bytes; output R (elliptic curve point, 256 bytes: 128 for x, 128 for y) and S (16 bytes). Total PCK(R,S) = 256 + 16 + 1 (delimiter) = 273 bytes (see RFC 6508 Chapter 4).

Signature is 129 bytes. IMessage fields: version(1B), Kdf version(1B), Symmetric encryption version(1B), Root key version(1B), domain(16B), CSB ID(8B), CallerID(16B), CalleeID(16B), Timestamp(8B), Rand(16B), (R,S_PCK)(273B), signature(129B), reserved(2B). Total = 488 bytes. Signature uses ECCSI (r, s, PVT) per RFC 6507, covering entire IMessage excluding signature.

VoLTE number is used directly. A 'Hashing to an Integer' function (RFC 6509, Section 5.1) is applied, output is an integer within 1024-bit length. Hash function controls output between 0 and n-1, where n is the order of the SAKKE elliptic curve (RFC 6509).

In IMessage, the VoLTE number is the original number, not the hash. The number is compared with the communication layer number to prevent IMessage replay attacks.

A unique domain needs to be entered by KMS admin when initializing KMS. Maximum domain length is 16 bytes.

Reserved is just for byte alignment, the value is all 0.

See TS 33.180. CSB ID is a random number used to identify a call session.

Root key version identifies the KMS domain root key. Each time KMS resets the domain root key, version number increases by 1. KMC must find matching private key certificate and KMS public key based on root key version in IMessage.

See Q30 in this document. KDF follows RFC 3830 (MIKEY) and RFC 3711 (SRTP) for key derivation from PCK, Rand, and CSB-ID.

The signature covers the entire IMessage, using ECCSI algorithm with private key SSK and PVT (see RFC 6507).

First: compare whether the calling VoLTE number in IMessage is consistent with VoLTE communication layer. Second: check IMessage signature using ECCSI algorithm with input (caller_volte_number, KPAK).

IMessage signature using ECCSI provides non-repudiation.

IV (Counter) follows RFC 3711: Salt (SRTP Master Salt, 128 bit) + SSRC (32 bit) + ROC (32 bit rollover counter) + RTP SN (16 bit sequence number). First 108 bits calculated as shown, last 16 bits counter = 0. CTR auto-increments counter by 1 after every 16 bytes.

Currently free from identity spoofing threats: (1) IMessage number compared with VoLTE communication layer number for consistency; (2) Sender signs IMessage with signature private key, receiver verifies; (3) Timestamp added to prevent replay attacks even when VoLTE communication layer is compromised (e.g., operator issues fake SIM with same number).

The signature of IMessage ensures non-repudiation.