Enhanced Security for A2P SMS using SMPP with TLS

04.12.2020
guide-image

EMnify now offers SMPP over secure SSL/TLS as an enhanced security feature for Application-to-Peer (A2P) SMS.

As described in a previous blog post on the topic, SMS is an important feature for IoT and M2M developers and enterprises. SMPP is how applications send and receive large amounts of SMS messages to and from mobile devices. When it comes to A2P automation, SMPP remains a strong favourite, particularly for configuring large numbers of cellular devices over-the-air. On the EMnify platform, this can be simplified using an SMPP connection with EMnify's Short Message Service Center (ESMSC).

How it works

SMPP uses the client-server model of operation, where the EMnify SMSC acts as a server which awaits incoming connections from clients. The clients here are typically application servers owned by a customer who can then programmatically send SMS between the EMnify SMSC and their devices. With delivery reports of sent SMSs easily accessible to the EMnify API, customer application servers can intelligently roll out updates incrementally without disrupting service to all devices at once.


Enhanced Security Blog graphics-15

 

Why is TLS important for SMPP?

The Short Message Peer to Peer (SMPP) protocol is an open, industry standard. It was designed to provide a flexible data communication interface for short message data between devices (typically referred to as ESMEs) and the SMSC. It is a clear-text binary application layer protocol and, additionally, has no security measures specified. Our blog post on SMS and Voice Service Attacks describes some of the most common threats leveraged by attackers. If users are sending potentially sensitive information via SMPP, the lack of built-in security features and the fact that the protocols are open to anyone needs to be seriously considered.

EMnify addresses the weaknesses in the protocol itself by introducing Transport Layer Security (TLS) for SMPP. TLS encrypts the segments of network connections directly at the application layer which ensures secure end-to-end transit at the transport layer. Secure SMPP (SSMPP) is therefore better suited for cases where confidentiality, integrity and authentication are required.

Additionally, external SMS originating from other mobile devices can be blocked by the platform so that only the device owner can send / receive SMS to and from the device – only once their application is authenticated in advance.

Benefits / Summary:

  • Send secure SMS programmatically via the EMnify SMSC
  • Route messages directly from customer application to EMnify platform, to customer device
  • Bi-directional communication as devices can in turn send SMS payloads

If you would like to benefit from TLS security on your SMPP connections, please contact our support team at support.emnify.com.

What can your connectivity provider do for your device security? 

Check out our Guide for Cellular IoT Securityfor 25+ best practices
to ensure a secure IoT solutionfor your business.

New call-to-action

Related Posts

Image for post How to send and receive SMS via the API?

How to send and receive SMS via the API?

To submit SMS directly from your application to an endpoint using our API, the following API call needs to be made: POST https://cdn.emnify.net/api/v1/endpoint/{endpointId}/sms Required Headers: Content-Type: application/json Authorization: Bearer {auth_token} JSON Body: { "source_address": "12345", "payload": "This is the message text!" } To receive SMS on your application server from the device you will need to first set up a Callback URL in the Service profile assigned to that endpoint: Set the API URL on the "SMS" tab - select "RestAPI" on the drop-down menu for “Interface” Select the “configuration icon” next to “RestAPI”, input a purpose (name of your choosing) and the URL You can also set up a "Secret" (optional) The EMnify system will then send the MO SMS as a JSON payload if the destination address of the SMS is an invalid MSISDN (8 digits or less). A2P / P2P Routing Our system distinguishes A2P SMS (application-to-person) from P2P SMS (person-to-person) based on the length of the source (MO SMS) or the destination (MT SMS) address. If there are 8 digits or less (i.e. an invalid MSISDN), an SMS will be considered A2P. If there are 9 digits or more, an SMS will be processed as MSISDN and will be considered P2P. To dispatch SMS MO to your application (A2P) and at the same time have P2P SMS enabled, the destination number (dest_address) must be limited to 8 digits or less. A detailed description of the SMS API you can find in our API Documentation.