Operator plans with Open Gateway are an attack on your privacy

Which operators will use Open Gateway?

Right now there are more than 20 companies that are within Open Gateway, with the capacity to reach more than 3.8 billion people. There are currently eight standardized APIs under the “CAMARA” project that is openly available on GitHub, and where we can see the source code of each of these APIs and what is the purpose of them. Operators such as Movistar, Orange and Vodafone are present and developing the different APIs of this project.

This new combination of technologies and evolution of operators is supposed to offer innovative services and solutions, with real uses and applications such as industry automation, autonomous cars, remote surgeries and interactive games. In addition, they have also placed special emphasis on improving emergency management, holographic communications and virtual worlds. The president of Telefónica, Álvarez-Pallete, has declared that these services will represent “the definitive challenge for the networks of telecommunications companies”, and that “without telcos there is no digital future”.

Another very important aspect is that this project has been supported by large Internet companies such as Amazon AWS, Google Cloud and also Microsoft Azure, and that is that through these platforms access is guaranteed to thousands of developers so that they have easy and fast to all API functionalities.

This all sounds very cool and very futuristic, however, Open Gateway is in direct conflict with your privacy as an Internet user , and it could also attack net neutrality . We must bear in mind that all companies that pay operators to access the APIs will have access to a lot of operator customer data, and this poses a serious risk to our privacy.

This is how Open Gateway will attack your privacy on the Internet

This project currently has more than 10 different APIs that are focused on carrying out different actions, some of which directly threaten your privacy and will allow applications, companies and even operators to be fully tracked in real time (even more if possible). Next, we are going to explain which are the most “dangerous” APIs for your privacy.

AnonymousSubscriberIdentifier

This API provides the company that has access to it, to obtain an anonymized fixed identity of an end customer who uses a certain mobile device, in addition, a very important aspect is that we will have the same identity, regardless of whether we change our mobile phone or SIM card. Whenever an end customer tries to access Internet services, we will have a fixed identity to “associate” with.

Right now the scope of this API is only limited to 4G and 5G networks , however, in the official documentation they indicate that this is only the first stage, so we assume that it will also soon be available in fixed Internet networks such as fiber optics .

• How does this affect you? If up to now, with cookies and supercookies, we were already being monitored enough and it was difficult to maintain our privacy, with this, not only will the operators know everything about us, but they will market this information, since the companies will pay to access this API.
• Why is the operator interested in doing this? To make money trading our data, companies will pay for API access and then have access to all of our data.

Operators have recently launched TrustPid , which is a “supercookie” at the operator level, with the aim of tracking us, as this new method is basically the same, but with the aim that other companies can access customer data to offer them advertising or some service.

IdentityAndConsentManagement

This API is in charge of regulating the privacy of the user , the platforms of the operators (Network as a Service) must be built with the focus on privacy to fully comply with data protection regulations, such as the GDPR of Europe . Thanks to the GDPR, some CAMARA project APIs will require user consent to access the data. Therefore, it will force operators to provide means and solutions to capture data from their customers, store this data and manage consent throughout the entire life cycle.

If this is not contemplated, the CAMARA APIs will not be able to be implemented, since they will have to comply with the GDPR of Europe. Operators will have to build a solution to incorporate the identity of the end user and/or service subscriber, since both could be different, the same holder could have different numbers used by different people.

• How does this affect you? What this API will do is “guarantee” your privacy, asking for your permission in cases where current legislation requires it.

Now it will be more important than ever to read all the conditions and terms, it will be something similar to the cookie “banner” that we currently have on all websites.

Device location

This API provides the company that contracts the service with the possibility of checking the location of the device. In a first stage, it is only planned for 4G and 5G networks, as explained in the official documentation, however, supposedly, fixed fiber optic networks will follow later. Specifically, what this does is check if a device’s location is within an area specified by the coordinates (latitude and longitude) provided by GPS if enabled.

Currently, this API only provides the verification of the final location, to do this, the mobile device will have to pass information such as the “ueld” which is basically an external identifier such as the msisdn, IPv4 or IPv6 address, it will also provide the latitude and longitude, as well as an expected value between 2km and 200km around. The client will ask if the location of the device is within this “circle” created, the reason for having a range between 2km and 200km is that, by triangulating through the antennas, we have such a large range.

• How does this affect you? Right now there are methods to falsify the location provided by the GPS, for example, we can indicate that we are in Galicia when we are really in Madrid, and the applications will believe that we are in Galicia. However, with this API this will no longer be possible, because the operator will locate us in specific mobile antennas, and the data will not match, therefore, we will not be able to falsify the location.
• Why is the operator interested in doing this? If the operator sells our real location to different applications, such as Tinder-type dating applications, they will be able to confirm that we are indeed located in the area where we say we are. Currently there are applications that allow you to fake the GPS position.

As you can see, with this API they will be able to physically locate us anywhere and there will be no way to prevent it.

DeviceIdentifier

This API provides the possibility of obtaining the identity of the final device that the client is using, it is basically obtaining the IMEI code of the terminal and knowing both the brand and the model of the terminal. This is already done currently because part of the IMEI code identifies the manufacturer brand, this is nothing new, but it is true that now external companies will be able to access information on what our mobile is, to send us advertising for their new terminals or the competence.

This API, if it is related to the AnonymizedSubscriberIdentifier API , is the perfect combination to know everything about us, including what mobile we use, and extrapolate the purchasing power of customers.

• How does this affect you? By itself it only affects that they will be able to know the brand and model of the mobile terminal, something that is already known because the IMEI says so. The problem comes if they combine it with other APIs and more information, they could know even more about us. If you have an iPhone, it can be extrapolated that you have a high purchasing power, and be able to send you advertising for premium products.
• Why is the operator interested in doing this? If the operator sells our real location to different applications, such as Tinder-type dating applications, they will be able to confirm that we are indeed located in the area where we say we are. Currently there are applications that allow you to fake the GPS position.

As you can see, one more API for data collection and its sale to anyone who wants to enter Open Gateway.

NumberVerification

This API is intended to verify that the phone number provided is the one actually used on the device. In this way, it is verified that the user is using the same phone number that is declared on the device. Of course, it makes it possible for a service provider to verify the number itself, by returning the phone number associated with an access token from the authenticated user.

This API allows you to check in real time the phone number that is being used on a mobile, this is exclusively focused on 4G and 5G networks, since Wi-Fi connections will be outside of this API. It has two methods to check the phone, the first is by getting the comparison result, and the most worrying is that the customer can send your phone number of the device they use, so they can verify it themselves.

Another important feature is that this API will use mobile network connections directly to verify possession of the phone number in the background , no user interaction is even required. There are no one-time passwords received by SMS or using authenticator apps like Google Authenticator, it’s much simpler and more transparent. This API can be used to register in the service and also to check later that we have not changed our mobile.

• How does this affect you? A third-party application can receive your mobile number directly, nothing to authenticate by the received SMS (regardless of the mobile number you have indicated), now companies will directly receive your real phone number that you are using.
• Why is the operator interested in doing this? The operator can sell the mobile phone verification service to an external company, it will no longer even be necessary to put our mobile phone and validate it with a code by SMS, but the company could directly receive our mobile number.

Imagine that you want to keep your “good” mobile number a secret for services like Twitter or Facebook, and only use your good number for banking and personal things . Now you will not be able to put the number of your secondary line to validate the code with the SMS message received, or use SMS message reception services on the Internet. Directly companies will know yes or yes your mobile number.

This service will not work if we do Tethering, if we are on Wi-Fi networks or use VPN connections.

CarrierBillingCheckOut

This API makes it possible to provide companies with a way to pay for their services through the customer’s bill from the telecommunications operator. Currently there are different services that can be paid through the operator’s invoice, this is a step further since anyone who has access to Open Gateway will be able to charge purchases made or subscribe to digital content directly on the invoice.

The positive part is that we will have an easy and fast way to pay, directly on the invoice. The negative part is that in the past there have been many problems with subscriptions that have not really been made by customers, either due to mistake or ignorance, so this should be looked at very carefully from now on, because many more companies will They could adhere to this API to sell their services through the operator’s bill.

This API does not seem bad to us for those who want to pay for the services through the bill of the telecommunications company, but as long as there is some method of unsubscribing that is efficient and easy.

Net neutrality in check

There are some Open Gateway APIs that are specifically focused on prioritizing some services over others on the Internet, when there is supposed to be a certain “net neutrality”. This clashes head-on with this principle, since the companies that pay will have better connectivity, and those that do not, will simply work worse because those that have paid have “taken over” all the available bandwidth.

QualityOnDemand

This API allows companies to request stable latency or minimal throughput in terms of speed, all managed by telecommunications networks, without the need for advanced knowledge of 4G or 5G systems, or the global complexity of systems. telecommunication systems. In this way, if a company such as an IoT industry, virtual reality games, or real-time video transmission, needs a series of specific requirements, they can “configure” the network to guarantee minimum latency and minimum speed for that these services work perfectly.

What this API will do is prioritize the data of the companies that pay to access Open Gateway, the rest of the companies that do not pay will have what is known as Best effort or “best effort”, without latency guarantees or minimum speeds.

• How does this affect you? Net neutrality is in check, it is possible that you use certain services that will work very badly because other companies are paying to have top priority. Imagine that you go by car and pay the DGT to be able to overtake on the left and right at the speed you want, and, in addition, they provide you with a siren in the car to skip the traffic lights. There comes a time when, if many companies do this, you will necessarily have to slow down, you cannot give top priority to everyone. When a service is prioritized it will always have an impact on others that are not prioritized.
• Why is the operator interested in doing this? The operator will receive income for prioritizing the traffic of companies that pay. Companies will see latency reduced and speed guaranteed. Anyone who wants a connection that works perfectly will have to go through the operator’s “box”.

The main problem with this is that there will be a tier 1 internet and a tier 3 internet. While those who pay will have guaranteed latency and speed, those who do not will have best-effort with no guarantees of anything. In practice we could see that certain services will work worse (those that do not pay).

APIs that we think are useful

There are some Open Gateway APIs that we do consider interesting and useful in order to improve user security or their connectivity. We will explain what they are and what exactly they do below.

DeviceStatus

This API is the least “dangerous” in terms of our privacy, basically what it does is tell the company or client that contracts Open Gateway, if the end device has lost connection to the network, has reconnected, and even if we are roaming. Right now, this API will only be available for 4G and 5G networks, which is where it makes sense, after all, although they could add more features in the future for fixed networks.

This does not affect privacy too much, because currently the operators already know if a customer is roaming, has disconnected from the network or has reconnected. In addition, we believe that it is a positive thing because it will allow them to detect possible problems at the network level in certain locations. We support the use of this API with the aim of improving networks, because when it detects a fall, it is possible to know exactly which is the last cell tower that has been used.

OTPvalidationAPI

This API can be used to send short-lived one-time passwords (OTPs) to a phone number via SMS, and automatically validate it, to provide proof of possession of the phone number. Other important features is that it can perform real-time checks to verify that the user who owned the device has the indicated mobile phone number. This allows to provide a frequent OTP to add a security layer to different services.

In the official documentation, it states that one-time passwords via SMS is a secure method of providing access to an application or conducting a transaction. However, with the threat of Sim Swapping we believe that this is not the best , in fact, for security reasons, it is best to use a local authenticator application and even an application of the service itself . For example, the Caixabank bank never sends SMS messages, but everything is done through its Caixabank Sign application with our password or fingerprint.

This type of authentication already exists, but now manufacturers will have “native” access to authenticate customers. In our opinion, this currently does not bring anything new, because current SMS already do the same, although it is possible that we no longer have to enter the code, but it will do so automatically.

SimSwap

This API is the most interesting of all to deal with SIM Swapping, one of the main attacks on users to steal their passwords by SMS (as recommended by the previous API), and access banking or online services with two-factor authentication. this type. As we have explained before, using a two-step verification method via SMS is not at all secure, but this API called SimSwap could improve security.

The purpose of this API is to request the last date of SIM exchange performed on the mobile line, or to check if a SIM exchange has been previously performed during a previous period. This allows real-time verification of the activation date of a new SIM card for a certain number. This feature enables fraud prevention and greatly reduces the risk of fraud.

Practical use case:

Let’s imagine that a bank like BBVA (which does send SMS messages for certain things) buys access to this SimSwap API, before sending an SMS message to a phone to verify its identity, it can verify if there has been a SIM change, and decide not to send any SMS code. Usage example:

• If there has been a SIM change in the last week: does not send any SMS code and sends an error through the application or online banking.
• If there has not been a SIM change for 1 year or more: send the SMS code because you have verified that the phone (with great certainty) belongs to the client, and that they have not made a SimSwap attack on it.

Although this API is really interesting and improves security against these scams, SimSwap is something that operators must control very well so that no one can change a customer’s SIM card and cause a hole in their bank account.

HomeDevicesQoD

This API is similar to QualityOnDemand, but is focused on fixed fiber optic home networks. This makes it possible to implement traffic management policies in addition to the operator’s Internet connectivity services. The API will be able to configure the router with the DSCP protocol to prioritize certain downloaded network traffic within the user’s home network for a given home device. A very important aspect is that the DSCP only prioritizes the traffic within the network, not in the operator’s network, in addition, it is only capable of prioritizing the download of the data (from the router to the client), the traffic profile only Applies to home devices that are connected by WiFi.

This is basically like having a QoS configured on the router, but configured by the application or service that we are going to use. We can see that this service, like a video call, works much better and smoother because it has configured the QoS of our router automatically and completely transparently.

• How does this affect you? This has its strong points and its weak points. The positive part is that we will have a better user experience when making video calls, or playing online, as long as the company pays for access to Open Gateway. The negative part is if we are using several services simultaneously, when we have “high priority” on many devices, this means that they will all continue to have the same priority because they cannot be prioritized at the same time.
• Why is the operator interested in doing this? The operator will receive income for allowing the company to configure the QoS of the router used by the client, and all this transparently for the user.

Logically, if you change the operator’s router and buy one yourself, you will not have this functionality, both for better and for worse. What this API allows is to improve the QoE (quality of experience) of the user for those services that require it, such as VoIP calls or video calls among other uses.

EdgeCloud

This API makes it possible to provide the edge router closest to the device from which the query has been made, with the aim of optimizing the route from the origin to the destination as much as possible. This will allow to know which MEC platform is closest to the client, so that it has the minimum latency and the maximum possible speed. By being physically closer, the propagation and round-trip latency of the data is reduced, causing us to have less latency and also a higher real speed.

• How does this affect you? The application or service you use will work better for you, with lower latency and higher speed because you will be connecting directly to the closest server, and not having to connect to a distant server.
• Why is the operator interested in doing this? The operator will receive income for giving information about the closest server for a certain application. However, this is something that is already done today through exterior gateway dynamic routing protocols such as BGP, if BGP is well configured, optimal routes will always be provided. This seems to go a step further to improve the end user experience, since geolocation will come into play, and it will take into account the internal routing of the operators’ AS (which usually use IS-IS or OSPF).

We believe that this API is quite interesting to provide a better and faster service, but that operators have to pay to have these improvements, we believe that they could do it by default, because this will also improve the efficiency of their networks, and avoid that certain nodes collapse because all the traffic travels through them, is a win-win, however, it does not seem bad to us that they want to earn more money by providing “premium routing” for those who want to pay for it, but as long as they do not harm the rest who do not pay

Conclusions

As we have seen before, there are APIs that are specifically focused on violating users’ privacy , collecting even more data than is already collected, and trading the data to sell it to whoever pays to access Open Gateway. We believe that this new technology could be very dangerous for the privacy of the users, because you will not even be able to get rid of all of them using VPN networks to mask the traffic, since it will be done natively on your smartphone through the antennas of the operators .

Other APIs are specifically designed to improve the end user experience , but the problem is that net neutrality could be greatly affected . If companies and brands pay to have the highest priority, what will happen to those that do not pay? In any QoS, if what is done is to prioritize 80% of the traffic (those who pay), to begin with that traffic will not be a priority and we will be almost equalizing the priority if we do not apply QoS to it, and the remaining 20% could see latency of the increased connection and also the speed will be clearly lower. There are some APIs that we do consider interesting in this regard , such as the one for HomeDevicesQoD to activate the QoS of the local router and provide very good performance over WiFi, and we also see the one for EdgeCloud quite well, but as long as the routing of the connections is not affected. companies that are not going to pay.

Finally, there are some very interesting APIs such as SimSwap to prevent fraud, without a doubt, this is our favorite of all of them, because it will allow banks to check if there has been a recent SIM change, so as not to send the OTP code via SMS and send an alert notice.