Validating the Security of Mobile Authentication Apps

This is gonna be difficult. So I have to hold the microphone on the clicker and the talk at the same time and I'm a man, so bear with me. Let's see. Yeah, it's over there. Before I actually go into the presentation itself, I have one request or actually a demand. Please watch the Eurovision context next Saturday. My hometown, hometown guy Karia, is actually performing there and it's fantastic. It's Ramstein meets disco meets rap, and it's a hundred percent, 110% kitch. So it's absolutely perfect for Eurovision. Anyway, I'm here for the, from the National Cybersecurity Center of Finland. And you might be wondering what does that kind of organization do an event like this? And there are a couple of reasons. And basically the biggest reason is that what we've done since 2016 is that we have actually put in place regulatory requirements for authentication providers.
And the same kind of requirement is coming with the A 2.0 for the wallet providers and such. But we have done that already in 2016, and part of that is underlined there. So identification means that's the lingo. Weird language authenticators is another term. It reminds me of Flash Gordon and skeleton, but I'm, I'm weird like that. So anyway, what we talk about when we say identification means we need mean the authenticators. And in this session, especially in the mobile authenticators or the mobile authentication apps, and Alexander was just saying that, you know, people are moving away from the mobile authentication apps. And I couldn't disagree more because everybody, at least back home is moving towards mobile authentication apps, especially in the E I D field. And I gave a presentation two years ago about this, let's say the federation network that we have in Finland. We have 13 private sector IDPs in Finland, 10 of those are banks and three mobile network operators. And they all provide eids to the citizens. So I have a mobile certificate and a banking id and of course one government issued E I D card that no one, no one is actually using. So I, I have that, but it's just a travel document for me.
And like I said, these are the main categories. Banks issue these mobile authentication apps and they are of course available for iOS and Android. And they are from multiple different sources. And the mobile certificates, it's a certificate based, it's the same system that is used for example in Estonia and it's a SIM based. So in a sense it's, it's a smart card yet again, it's not. And when I talked about certification in the previous slide, I'm talking about a certification of the whole system. We require our identification providers to go through a certification process procedure or an audit cycle every two years. And they have to audit the whole system. They have to audit the facilities, personal IT systems, communications, APIs, and of course the authenticators. And now we talk about these authenticators as these mobile apps and the mobile certificate.
The problem in those 2016 was how do we actually validate the security of these apps? They started to come to the market around that time. I think we got the first audit report from a bank in 2017. And it was scary to read, really scary. And sometimes these apps, they get embedded into a a wider app. I mean you have different approaches depending on your bank that you're using. Some banks embed these authentication functionalities into their banking app. And some banks, for example, separate them to a a standalone app. But the common thing is that almost every time, almost not always, almost every time there's an SDK and that's provided or outsourced from somewhere. So there's a vendor who provides the SDK to the bank, and the bank then integrates that into their own application, does some branding or embeds that into a wider application. And we really struggled with the fact that there was no way of validating all these different apps in a uniform way or so that we can actually compare the, the results.
We go into the history a bit. Some of these are more recent, but what I'm trying to say here is that why we came to a conclusion that we came to in 2019. So common criteria, cc, yeah, well good for let's say smart cards and environments that are stable, static operating systems that do not change and these kind of things. And I was actually a part of Alda when we certified a SIM based mobile authentication app. So it's, it's doable. But for the apps, absolutely no, I mean the operating system changes constantly and the app gets updates all the time. So not suitable. And this is what we found out back then. Iso, if you know that you can look it up. It's quite recent, it's fairly okay, but it's about biometrics. So it doesn't really help us. It would've, it would not have helped us in 2019 when we made a decision to do something about this situation. Fido, oh sorry, ET before that the target of evaluation t o a is the whole phone that's going way overboard. So for the purpose of validating the security of a mobile authentication app, not suitable Fido, pretty cool.
Still a bit too Fido specific. So now that we are renewing our stuff, there might be something that I can steal from these guys. For the new thing, OSP has this mobile application security verification, standard MAs and close. That was really, really close. And that was the basically the only thing available at the time in 2019. Then the CSI csa, so cybersecurity act just recently. Are we there yet? No, we are not. And then GSMA has their own approach, which is called Sam 0.01. And again, it's concent, it concentrates on the, let's say the hardware element of the mobile phone and the idea that the, the actual control is with the mobile mobile operator. So not suitable. And it wasn't available at that time when we were trying to figure out how to verify these authentication apps. This is coming and most probably this is something that we can, as an supervisory authority use as is in the future, but we are way, way far too far away from that. So, and this, this is kind of like the snapshot of today, back in 2019 when we decided to do something about the to the issue, most of these things were not there. So what do you do? You have plenty of standards and then you have, well, a bright idea, you know the dilemma, I mean plenty of standards. Well let's create another one.
We chose the O vasp as our starting point. It's a pretty good standard. They call it the standard. Maybe that's just a marketing, but it's pretty good. And what I liked about it is that it's kind of like agnostic in a sense that they don't, for example, talk about protocols. And we tried to, when we, we were creating our own standard or adaptation of muscles, we also tried to keep away from being, you know, tied to any kind of a protocol or specific, specific things. And we did it this together with the banks and the mobile network operators and the audit companies who actually do the audits. And that proved to be quite valuable. So we expanded the OASP paper with about, let's say, I don't know, 20, 30 new criteria. We tightened something up and we loosened something from the OASP thing and we ended up with something that was usable to us, but also to the auditors.
Those guys that are validating the security of the mobile apps. The reason is that the, the guideline that follows the overp stand standard, it has really good guidelines on how to actually do these verification steps, what kind of tools that you have to use and what steps you have to take in order to verify the app. So any consultant or a pen tester worth their salt can extrapolate how to actually verify all the added beats that we did for the muscles. They really have to come up with a better acronym for that. And that's why that's what we decided to do in 2019. So we adopted muscles and expanded a bit and we came up with a list of criteria. And for the, the important bit for us is of course, because we are supervising authority and our actions are based on AI regulation, national law, and then national regulation, we had to have legal grounds to demand all these kind of things that we put in there.
So for example, it starts with a very, very basic requirements, no your components and it goes on and on. And then there's a small big, sorry, kinda the biggest check section about the authentication part itself, but I'd say like 65, 70% of these criteria are basically created to verify the overall security of the mobile app. And the added stuff is especially catered or especially created to look at things that are related to authentication. Like how do you store these secrets? How do you for example, use biometrics and these kind of things. And it's not too long. It might sound a bit daunting over a hundred criteria, but like I said, there's a good guidance on how to actually accomplish an audit of a mobile authentication app using this just by looking at the OVAs Pike OSP guidelines and how they say that okay, do this for the, for the audit.
So it's been running now, let's say three cycles we started and we got, like I said, pretty scary results. It's been improving all the time. And I have to say that the SD case that the vendors are providing to our banks, they are from international operators. So international companies, it's being improving. But still this is something that baffles me still after six years, almost every time that we receive a new auditor report that we have to go through, there are these information security hygiene 1 0 1 things cropping up, like not knowing your software. That was the first criteria there they have libraries that they actually haven't updated. So unnecessary risk, risk surface for the, for that one, test code travels. What happened?
Okay, test code travels to production. Again, a common issue testing this is, this is again something that how can you test so poorly? You do not include any kind of negative, negative use cases or negative test cases. And that has resulted into some actually a public publicized breaches within the providers. So we added some additional requirements to the, to the audit guidelines to actually to include a negative test cases as well. And the business, they are providing a business, so they are banks and everything, so they want to cater all of the possible clientele and that means that old operating systems are allowed. We are getting rid of that bit by bit, but still there are like operating systems that are allowed that are three years end of life already. However, the starting point for the whole criteria is that the mobile authentication app is always in a hostile environment.
So in a sense it's fine, but still I would like to see them requiring a bit more fresh oass. So if you have a mobile authentication app and you think that it is secure, I would suggest that you consider, again, it might not be the case, but this is how you do these things. You find out maybe a bit late because of the breach or you have someone else look at the mobile authentication app that you are buying or you're providing. I mean, if you are providing this kind of way, if you follow that criteria, a similar criteria and you provide to your customers evidence that you have audited this and these kind of things, that's a selling point in my mind. But also if you're buying something you might require from the vendor, some kind of proof that it is actually relatively secure. So Mabus has provided, proved to be really effective and good tool actually for our vendors and also for our audit companies.
It's not too massive, it's a quick thing to do actually. And they have no routine for that. So it doesn't take too long. It's not like CC certification, but it still gives you good results and you can actually integrate these kind of requirements also into your own development if you are developing a mobile authentication app. And yeah, it's free to use, I'm from the government, it's no secret. There's a link in behind after this presentation, you can download it and if you decide you can, you know, show it to your vendor or you know, possible vendor and say that, okay, can you run through this using an independent third party? And then you get verification that it might be actually relatively secure. Having said that, this criteria is only created for e IDAs level, substantial, so not for high. So if you know about LOA and e IDAs, it's perception substantial only. But the thing is, we've reported numerous vulnerabilities to the vendors and all these SDKs have improved over the years and it has benefited probably all of us because those are some big names that are buying or selling to the banks. So I can't say names, but yeah, I would say that in your pocket there is something that probably has benefited from this work. Even Microsoft have received couple of reports on vulnerabilities. That's it. There's the link. Go download it. It's on the, on the slides when you receive them. And any questions?
I'm, I'm afraid we have no time for questions. We have to jump into the next session, but please a round of applause to.