The problem with cloud-based app security

As we delegate more and more of our daily tasks to smart devices, so apps are increasing in importance.

We’re at the point now where for some businesses their app is actually their main asset.

Take mobile banks, for example. They don’t have a physical bank for customers to visit. There’s no legacy of conversations with bank managers to build trust. The only way these mobile banks can secure and keep the trust of their customers is through the app itself.

That’s why app security is so vital for business success these days. After all, a data breach can lead to this trust evaporating in an instant.

So, choosing how to protect your app has become a pretty big decision. Different apps need different layers of security.

We had a conversation recently with a potential customer who was making some initial decisions about how to protect their app. And as part of that process they asked us about cloud-based app security. They had heard about it and wanted to know our opinion on it.

We had to be honest. We told them that we don’t recommend cloud-based app security.

In this article we’ll explain why. We’ll touch on why we think local protection is more robust. But we’ll also suggest one way companies might protect their apps online that provides a little bit more security.

We’re approaching the end of 2020. And as such we’re all pretty well-versed in the concept of self isolation. If we want to limit the spread of covid-19, then we need to keep a safe distance from one another and, where possible, stay home.

As it turns out, self isolation isn’t a bad idea for apps, either.

You see, there’s a principle in cybersecurity that says that the fewer access areas you have, the better. This makes sense when you think about it, because what you want to do is limit the opportunities bad actors have to attack.

This is one of the main problems with cloud-based app security in our opinion. Because the first step in the process is typically for you to upload an application container (APK or AAB for Android, and IPA for iOS) to the cloud. But as this application container makes its way from your computer to the cloud, it’s highly vulnerable. You can’t be sure that it won’t be altered or tampered with in some way before it arrives.

On its journey to the cloud, the application container might be intercepted. It could fall victim to a man-in-the-middle attack. Hackers might even manipulate it in order to carry out a phishing attack.

Imagine you register on a cloud-based security portal and successfully upload your application container. But later that day you receive an email or SMS telling you that you need to re-upload it because some vulnerabilities have been detected with the application.

“Just click on the link below to upload it again..”

Except that link is a malicious link. And the message isn’t from the cloud-based security company at all.

So, the initial act of transferring the application container is the first problem with cloud-based app security. But it isn’t the only one.

Another issue arises if your app contains security assets like API keys, security key materials, or login credentials.

You’re technically compromising your keys.

One way to tamper proof your app - which we’ve written about before on this site - is to digitally sign under your app to certify it. In an ideal world, this would be enough on its own. But more often than not that isn’t the case, because a bad actor can still re-sign an app and even upload it to stores to mislead people.

That’s not to say that signing isn’t an important part of the process. The signature under an app can be used as an input to calculate cryptographic functions that can then be used for wider protection measures.

However, carrying out this process on the cloud isn’t safe. Unless of course it’s done at the app store itself - whether that’s Google or Amazon.

We’ll come back to that later.

Integration can also be problematic on a cloud-based platform. The build server where you create the app before publishing it should really be offline (or at least in a private, secured segment of the network) so that hackers can’t change something in the server or modify the app. Again, being connected to the cloud means you’re adding more doors for bad actors to open.

This is even more of an issue when you consider that some large organizations have a dozen or more apps designed for different regions that follow specific regulations. What’s more, if your app has cryptographic algorithms that are subject to expert controls in one country, it might not be legally possible to transfer the app across territories.

So, if we don’t think cloud-based app security is the best way to keep your app safe, what do we suggest?

Well, there are two main alternatives. The first of these is to protect your app locally, which is what we would recommend as the best option.

Why?

At Licel we often refer to the cryptographic puzzle when we talk about robust local protection.

What we’re talking about here is ideal-world security that works with the final containers and keys deep inside your app.

From such a depth, a local protection solution can carry out cryptographic pre-calculations. That means if something has been modified in the protected app, then the cryptographic puzzle won’t be solved correctly. And because of that, the app will become inoperable.

This prevents any kind of tampering, re-signing, and injection of malicious logic.

With a cloud-based security platform, it simply isn’t possible to manage and protect this cryptographic puzzle with anywhere near as much integrity.

That's because the app isn’t isolated - as such it’s exposed to lots of risks. It means you're not in control.

But there is a second alternative to cloud-based app security aside from local app protection. In this second scenario, both the signing of the app and the robust protection we’ve mentioned above are carried out by Google or Amazon at their secure servers.

Most app stores use cloud signing to secure apps. The benefit of this approach is that the keys that are used are a lot more robust. The downside is that these companies have their own methodologies for signing and there isn’t anything you can do to influence that. And as the process still involves people, there’s room for mistakes to happen such as cloned apps being approved for uploading.

That said, this option - as yet a slightly hypothetical one - offers a lot of potential to make cloud-based app protection much safer (and more effective) than it is at the moment.

In a future scenario where Google or Amazon offer this same level of protection in a cloud-based environment, we might be able to recommend that too. But at the moment, the only robust approach is a local one.

The client in question was developing a highly-critical app. And so we also suggested that they use a Hardware Secure Module (HSM) to store their signing keys. That’s because files stored outside of such a module are open to theft. Just one more reason why an online, cloud-based solution might have been problematic for them.

It's important to remember that we’re all pioneers in this application journey. Apps are now so entrenched in our everyday lives that it's easy to forget they've only been around for a decade or so. But there’s often a disconnect between the importance of an app to business success and the level of security it’s given.

Let’s protect apps in a way that’s worthy of their growing influence on the world.

That way we can make sure that it’s the end users who benefit from them rather than bad actors.