Definition
Key Management (Key Management) includes key generation, derivation, storage, distribution, and updating, and is the foundation of the security architecture. In cellular networks, after authentication, encryption keys and integrity keys are derived from the master key K through a KDF (Key Derivation Function), used for air interface encryption and integrity protection. Keys use hierarchical derivation to achieve isolation and forward security.
Key hierarchy and derivation
- K: Long-term key, stored in the USIM, never exported
- CK/IK: Derived during the authentication process, used to generate KASME/KAMF
- KeNB/KgNB: Base station-level key, updated during handover
- KRRCenc/KUPenc/KRRCint: Service keys, used for RRC encryption, user plane encryption, and RRC integrity respectively
Key updates and security
Keys are refreshed during switching, periodic updates, and algorithm changes to reduce the risk of long-term key exposure. 5G supports key isolation (e.g., different slices using different keys) and introduces KDF enhancements (e.g., HKDF) to improve derivation security. IoT eSIMs support remote key configuration and secure storage (e.g., SE, TEE), meeting the requirements of high-security scenarios.
Typical Use Cases
Air interface encryption, integrity protection, switching key updates, key negotiation for end-to-end encryption, etc. SimtoLink's IoT SIM cards use operator-standard key management, and the K in the SIM works with the network to complete authentication and derivation.
SimtoLink's IoT SIM cards follow operator-standard key management procedures. The K key in the SIM works with the network side to complete authentication and key derivation, ensuring air interface encryption and integrity protection. For high-security scenarios requiring end-to-end encryption, the SimtoLink cloud platform can integrate with the customer's key management system to achieve collaborative management of application-layer keys.
The long-term key stays in the card, and traffic keys change per bearer
In the cellular system the long-term key is written in the subscriber card, and the network side keeps it in the authentication center. Neither side sends that key onto the radio link. After authentication succeeds, a derivation function produces an intermediate key for the session, and further keys are derived for ciphering, integrity, and each bearer. A leak of one bearer’s key should not yield the long-term key, and it should not yield another bearer’s key. The test of isolation is: after the data bearer is replaced, key material captured on the old bearer cannot open the new bearer. If it can, the derivation inputs are missing a distinguishing field such as bearer or direction.
Once the long-term key is exported into ordinary storage, every later derivation loses its point, because an attacker can recompute from the root. Card-reading scripts, logs, and work orders should none of them contain this key. Replacement goes through the operator’s card-writing or card-replacement process, not by overwriting a field in an application configuration file.
After a handover, the key on the base-station side has to be derived again
When the serving cell changes, the key the base station uses must change with it. Otherwise the new cell can open packets from before the handover with the old key, and forward secrecy stops. Derivation can use a handover count or a next-hop parameter so the old and new base stations do not hold the same material. If either the device or the target base station did not update, handover signaling can complete and the user plane fails every integrity check. The difference from poor radio coverage is: the level is normal, the failure starts at the moment handover completes, and staying on the original cell is still normal.
A re-establishment inside the same base station does not necessarily change to the same material as a new cell. It depends on the re-establishment cause. Treating every radio re-establishment as “the key has been updated” makes the device use a key that is ahead, while the peer still uses the old one. The module should update according to the indication in the security-mode or handover command. It should not increment on its own from the local retry count.
Change the algorithm suite and the old traffic keys are void at once
Key derivation takes the algorithm identifier as an input. Moving from one cipher to another changes every traffic key underneath, even if the long-term key did not change. If the network side changes first and the device still uses the old algorithm, or the reverse, the whole stretch fails its checks. During the change window, avoid upgrading only one side. Switching from the null algorithm to a real algorithm also requires a fresh derivation. Do not carry the counter from the null-algorithm period into the new algorithm.
What a SimtoLink IoT SIM card keeps is the long-term key material operator authentication needs, used to derive air-interface keys after the device is on the network. Keys for the device cloud, firmware signatures, and service tokens are another set. Their lifetime is set by the enterprise. They are not replaced automatically at handover, and they do not migrate automatically because the card was replaced. When the platform connects to a customer key system, keep card keys and application keys in two stores. Using an application key to explain an air-interface check failure, or replacing the card to fix an expired application certificate, looks in the wrong layer.
The sequence number in the card and the one in the network meet only at resynchronization
Matching long-term keys on both sides is not enough to finish authentication. The sequence windows have to line up too. In ordinary operation the sequence number in the card is not read out and compared. Only when an authentication token falls outside the window and the device sends a synchronization failure does the network use the information the device brings back to push the window to a new position. After that one alignment, if the network side still issues old vectors, the next round fails again. Resynchronization is not a key change. It only aligns the count. Replacing the card again and again without synchronizing the vector cache still makes the new card’s window collide with the old cache.
The rotation rhythm of application keys should not copy this resynchronization. Air-interface keys change at handover and when the algorithm changes. Application keys change on certificate lifetime or business policy. The two calendars differ. Long-term material inside a SimtoLink card is managed by the operator card-writing process. When the enterprise rotates application keys, it should not require a card change at the same time. If authentication synchronization failures rise on the platform, check first whether vectors are cached past freshness. If application authentication failures rise and air-interface authentication is normal, check enterprise keys and certificates. Handling both failures on one work order writes material into the card that should not be written there.