Description
The Receiving Entity is a core functional component of the 3GPP secured packet framework, defined in TS 22.048 and TS 23.048. It is the counterpart to the Sending Entity and is responsible for processing Secured Packets. When a Secured Packet arrives over a bearer (e.g., SMS, USSD, or IP), the Receiving Entity performs a series of security operations: it verifies the integrity of the packet using a message authentication code, decrypts the payload if encryption is applied, checks for replay attacks using counters or timestamps, and validates the sender's authorization. Only after successful security processing does it extract the Application Message and forward it to the Receiving Application.
The Receiving Entity can be implemented in various network nodes or terminals. In Rel-5, the definition explicitly listed examples: SMS-SC (Short Message Service Centre), UICC (Universal Integrated Circuit Card), USSD entry point, or a dedicated (U)SIM Toolkit Server. This flexibility reflects the diverse deployment scenarios of secured messaging. For instance, when an OTA message is sent to a UICC, the UICC itself acts as the Receiving Entity, using the USAT Interpreter Security Functionality to process the secured packet. When a message is sent to an application server, that server may host the Receiving Entity.
In Rel-8, the definition was revised to remove the explicit list of examples and instead state that 'the Receiving Entity is the USAT Interpreter Security Functionality or the Security Node.' This change reflects the evolution of the architecture, where the security functions were more formally consolidated into these two roles. The USAT Interpreter Security Functionality resides on the UICC and handles secured packets for USAT applications, while the Security Node is a network entity that can process secured packets on behalf of applications. This clarification aligns with the growing emphasis on standardized security nodes in later releases.
The Receiving Entity is not just a passive receiver; it actively enforces security policies. It must be provisioned with the necessary keys and security parameters, often through a key management infrastructure. It also generates responses or acknowledgments that may be secured and sent back to the Sending Entity. The security mechanisms are based on symmetric cryptography, typically using algorithms like 3DES, AES, or XOR, as specified in 3GPP TS 23.048.
In summary, the Receiving Entity is the security guardian of the secured packet framework. It ensures that only authentic, unmodified, and non-replayed messages reach the Receiving Application, thereby protecting the integrity and confidentiality of over-the-air application communication.
Purpose & Motivation
The Receiving Entity was created to provide a standardized, reusable security processing point for application messages transported over wireless networks. Before its introduction, each application or service often implemented its own security mechanisms, leading to fragmentation, interoperability issues, and potential security gaps. By centralizing security functions in a dedicated entity, 3GPP enabled consistent enforcement of confidentiality, integrity, and replay protection across all secured packet applications.
The Receiving Entity solves the problem of trust in over-the-air communication. Mobile networks are inherently open to interception and tampering; without a robust receiving-side security layer, sensitive commands (e.g., SIM card updates, payment instructions) could be forged or altered. The Receiving Entity verifies the origin and integrity of each packet, ensuring that only legitimate Sending Entities can trigger actions.
Additionally, the Receiving Entity abstracts the complexity of security from application developers. Applications can focus on their business logic, relying on the Receiving Entity to handle cryptographic operations. This reduces development time and the risk of implementation errors. The evolution of the definition in Rel-8, which clarified the roles of the USAT Interpreter Security Functionality and the Security Node, further streamlined the architecture and made it easier to deploy in diverse environments, from UICCs to network servers.
What changed in its specifications
The latest release-to-release comparison of specifications that define Receiving Entity. Each summary describes the whole specification, not only this term.
Rel-5 added applet management commands, minimum security level specification, and a security layer relation to Open Platform architecture.
Full comparison in TS 23.048 →Release Timeline
Evolution Across Releases
An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.
Initial definition: 'this is the entity where the Secured Packet is received (e.g. SMS-SC, UICC, USSD entry point, or dedicated (U)SIM Toolkit Server) and where the security mechanisms are utilised. The Receiving Entity processes the Secured Packets.' This established the functional role and provided examples of implementation locations.
Wording changed: The explicit list of examples was removed, and the definition now states: 'This is the entity where the Secured Packet is received and where the security mechanisms are utilised. The Receiving Entity processes the Secured Packets. For the present document the Receiving Entity is the USAT Interpreter Security Functionality or the Security Node.' This reflects a more formalized architectural view, consolidating the security functions into two specific roles.
Defining Specifications
3GPP specifications that define or reference Receiving Entity, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 22.048 v500 | Security Mechanisms for SIM Toolkit | Rel-5 read |
| TS 23.048 v590 | Secured Packets Structure for SMS and UICC Management | Rel-5 read |
| TS 31.114 v800 | USAT Interpreter Transmission Protocol | Rel-8 read |