Securing IoT networks with private APN

In today’s day and age, every machine around us is ‘smart’. Ranging from smart homes and wearables to more complex machines like cars, planes and industrial machinery, devices are connected with each other and with the internet to enhance user experience, control machines remotely and use other benefits of connectivity. This network of connected devices that communicate with each other and share information over the internet is often called Internet of Things, IoT for short.

Every one of these devices should be authenticated with secure methods when connecting to the internet, else a perpetrator can falsify data, steal information or gain access to networks through unsecure devices and networks. Companies can manage this and take control of their network by deploying a private access point name network, private APN for short.

What is private APN?

The Private APN service utilises operator’s SIM cards for radio network access, but separates the data traffic in operator’s P-GW (LTE core network packet gateway) by the access point name (e.g. internet.company instead of operator’s own access point name). These separate private access points may have their own parameters for authentication, accounting, IP networks, IP address allocation, connection parameters, traffic accounting, priorities, and other functionalities. Depending on the P-GW capabilities, it is possible to move some of these functionalities and information to a separate RADIUS service, which is provided either by the operator or company utilising the Private APN.

The choices of authentication method are between PAP and CHAP. As can be seen from the picture, the deployment does not need extensive infrastructure for the AAA, merely a basic Radiator AAA licence and a backend of choice (AD, SQL, REST etc.).

Enhance coverage of in-door devices with Radiator SIM Pack

The private APN functionality can also be enhanced with Radiator SIM Pack. If the IoT device also has Wi-Fi radio and functionality, it can also utilise Wi-Fi access whenever within range of the company’s Wi-Fi network. In this case, the authentication would be done directly with SIM-based authentication methods (EAP-AKA, EAP-AKA’) and the device will have access to the company network via Wi-Fi, like illustrated in the next picture.

The benefits of adapting Radiator SIM Pack lies in coverage. While the monitoring and other IoT devices might not need the biggest bandwidth, reliable cellular connection can be an issue for in-door solutions, for example in warehouses. With Radiator SIM Pack, the IoT devices will connect to the company network securely over Wi-Fi, ensuring reliable monitoring and metrics.

Want to know more?

If you are building an IoT device network or want to enhance the security of an existing IoT device network, Radiator is the solution for you.

For more information about Radiator licensing, technical details or for any questions, please do not hesitate to contact us sales@radiatorsoftware.com

WiFi offloading vs VoWiFi

In recent years we have encountered a lot of customers wanting to utilize their networks more efficiently, and provide premium service for their subscribers. WiFi offloading and VoWiFi are popular ways to to extend the mobile operator’s network coverage into wifi, free bandwidth from congested cellular networks and improve user experience with better connectivity. The technologies share many similarities and both use a 3GPP AAA server for SIM based authentication.

WiFi offloading offers some flexibility in the supported authentication backends and the SIM authentication can be done through various HSS and HLR interfaces depending on what the mobile operator has available. This is especially important in roaming scenarios where the WiFi provider has agreements with multiple MNOs to offload their subscribers.

WiFi calling is more strictly standardised to support high QoS for the voice call, and also the handover between VoWiFi and VoLTE. This allows users to move outside the range of the WiFi hotspot and seamlessly continue the call over VoLTE, and vice versa.

Let’s take a look at the key differences between the two related technologies:

Comparison	WiFi offloading	VoWiFi
Purpose	Ease network congestion, Network CAPEX savings, Roaming cost savings, Secure authentication to private wireless networks: carrier, industrial, in-flight, underground, IoT	Ease network congestion, Indoor coverage extension, Combat OTT apps, Roaming cost savings
Relationship between MNO and access network provider	Agreement required between MNO and wifi provider	No relationship between MNO and wifi provider
Access network	Carrier or partner wifi	Any public or private wifi
Traffic	Data only	Voice and video calls
SIM authentication protocol	EAP-SIM, EAP-AKA, or EAP-AKA’	EAP-AKA
Supported HSS interfaces	SWx, Wx, Cx, S6a	SWx required
Supported HLR interfaces	MAP, SIGTRAN	Not supported
ePDG	Not applicable	ePDG mandatory
Security	WPA Enterprise	IPSec tunnel between UE and ePDG
IMSI Privacy	Yes, supported by Radiator	Yes, supported by Radiator

What is different?

The main difference between WiFi offloading and VoWiFi is the relationship between the mobile operator and the wifi provider: operator controlled data offloading always requires a prior agreement between the MNO and the WISP. WiFi offloading is often done in high traffic areas such as airports, sports stadiums and concert venues, since offloading users to WiFi is cheaper than adding microcells to boost the mobile signal. MNOs can invest in carrier wifi hotspots themselves, or make offloading agreements with wireless ISPs.

VoWiFi requires the mobile device to be connected to a wifi before attempting a VoWiFi call, but any type of wifi can be used for WiFi calling, including consumer home wifi. Therefore no relationship between the mobile operator and WiFi provider is required. However VoWiFi has specific technical requirements for the MNO: a HSS with SWx interface and ePDG are required.

Private network authentication

WiFi offloading technology is also applicable to private network offerings, such as industrial and IoT networks. SIM authentication provides a secure method to authenticate users into a private network using their SIM credentials and eliminates the human element of reusing and sharing passwords. In high security deployments the SIM authentication can be further combined with device IMEI check, to make sure that only authorised users and devices are able to access the private wifi network. VoWiFi is also possible in private networks, and can enable voice calls in challenging environments such as underground.

Interested in WiFi offloading or VoWiFi?

Radiator SIM Pack provides a fully featured 3GPP AAA server solution, with superb flexibility to connect with your environment. Please contact the Radiator team at sales (at) radiatorsoftware.com to get a quote.

Radiator provides IMSI privacy for EAP-SIM, EAP-AKA and EAP-AKA’ authentication

In many high traffic areas such as sports stadiums, shopping venues, or public transport hubs, mobile carriers may partner with the local Wi-Fi providers to improve coverage and user experience: mobile devices can be automatically connected to Wi-Fi instead of congested cellular network. Internationally, Wi-Fi roaming agreements also allow carriers to lower the cellular roaming costs. 

EAP-SIM, EAP-AKA and EAP-AKA’ are SIM-based Wi-Fi authentication methods used to achieve seamless offloading to carrier and partner Wi-Fi, with International Mobile Subscriber Identifier (IMSI) derived from the SIM card acting as a unique identifier for each user. 

On the first ever connection to such a Wi-Fi network, the mobile device communicates its permanent subscriber identity information (IMSI), which is then sent to the home operator for authentication. This identity is sent in the clear. A potential 3rd party adversary installing a Wi-Fi sniffer in the vicinity of such networks can harvest permanent identities and track users. This tracking can also be done by the venue or network owner when connecting to the Wi-Fi network. 

Because of this, mobile operating systems such as iOS15 will show the following warning when joining a Wi-Fi network without IMSI encryption: “your mobile subscriber identity will be exposed”. The similar situation can be seen from the pictures below. 

Privacy warning when authenticating to Wi-Fi network without IMSI encryption

 

Operators risk decreased user satisfaction for Wi-Fi offloading if transmitting IMSI in the open - it may cause users to feel their privacy is being compromised.

Radiator SIM Pack provides IMSI privacy protection 

The solution is to protect user privacy by implementing IMSI encryption for EAP-SIM, EAP-AKA and EAP-AKA’ authentication. As an operator, you can enable IMSI privacy easily: Radiator 3GPP AAA Server handles both encrypted and clear authentication requests. This means IMSI privacy can be offered to devices supporting it without affecting other users. 

Starting already from revision 2.5, Radiator SIM Pack supports IMSI encryption as specified in 3GPP S3-170116 document “Privacy Protection for EAP-AKA” (zip), and WBA’s IMSI Privacy Protection for Wi-Fi – Technical Specification. The feature is already implemented by some of our operator customers to cover their AAA server encryption. 

The latest release of Radiator SIM Pack is available for new licensees and for licensed customers with valid download access. To find out if Radiator SIM Pack suits your needs, you can contact us at sales@radiatorsoftware.com and a member of our sales team will be happy to assist you. 

You can also contact us to renew your support contract and get access to the newest release. A full history of Radiator SIM Pack releases is available on our website.

Radiator SIM support 2.4 released

We are pleased to announce release 2.4 of Radiator SIM support. This release includes support for SCTP multihoming and has a number of smaller enhancements and bug fixes.

Revision 2.4 detailed updates and fixes

• 3GPPAutHSS now supports Peer-Auth-Application-Id as DiaPeerDef selector. Requires Carrier module 1.5 or later and Radiator 4.20 or later.
• Added configuration parameter HSSRealm to 3GPPAuthHSS. This value for this parameter is typically the realm where HSS resides. If not set, messages’ realm is set from DestinationRealm parameter of DiaPeerDef used to forwarding messages to the HSS. Defaults to not set.
• Subscription-Id AVP is now added to SWm DEA messages to relay MSISDN to ePDG.
• Updated EAP-SIM, EAP-AKA and EAP-AKA’ permanent, pseudonym (TMSI) and fast re-authentication identity leading characters to match RFC 4186, 4187 and 5448, and 3GPP TS 23.003 suggestions and requirements. Because of historical reasons, EAP-SIM fast re-authentication and EAP-AKA TMSI leading characters were swapped. EAP-AKA’ non-permanent identifiers are now fully separate from the respective EAP-AKA identifiers.
• Removed obsolete configuration parameters TestNoMAP and GetReauthQueryEAP. Support for TestClient and TestVectorFile were removed from AuthAKA.pm and related files because they are obsolete. Use AuthAKATEST or ServerWXMAP based configurations for testing.
• A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
• SCTP multihoming is now supported. Requires Radiator 4.22 and Radiator Radius::UtilXS package.

Also, for more information, please do not hesitate to contact us at info@radiatorsoftware.com . See also Radiator SIM Pack product page.