Given the current prevalence of mobile devices, especially smartphones, it comes as no surprise that they are becoming more and more entwined with everyday aspects of our lives. We don't just use them to make calls, to text, or to browse the internet anymore. We can use them to do just about anything, and that includes using them as a means to provide our credentials.
Since people almost always have their phones on them, it makes sense -- to some extent -- to use them as a means to store and validate one's credentials. Banking information, ticketing purposes, access control -- they can all be handled through smartphones now. But this, of course, begs the question of just how safe the practice really is.
"That's possible with NFC, they're using that," says Dionisio Zumerle, a Gartner analyst, of the practice of using smartphones for access control purposes in the enterprise. "But you also have to take into account that a lot of methods they use are only available with certain hardware on certain devices. It's something that we see emerging, but it's not in the mainstream world just yet."
For those enterprises that do use mobile devices for storing credentials for things like access control purposes, there are some methods that are implemented to lock them down. The methods are not always particularly sophisticated, however; Irfan Asrar, a researcher for McAfee, says that these credentials are typically secured with native security.
"They may have some additional BYOD policies enforced on them," says Asrar. "But most of what we've been seeing has been using the basic authentication with the OS."
Zumerle says there are also some slightly more advanced methods of protecting credentials.
"With NFC there is secure element, which can be used to secure the credentials," he says. "Usually it involves a separate component, like a Smart Card or an SD card."
With secure element, the application code and data is securely stored and executed on the external chips. According to the Smart Card Alliance, the secure element "provides delimited memory for the apps and other functions that can encrypt, decrypt, and sign the data packet."
For those that are looking for a slightly more convenient means of using their mobile devices for NFC-based transactions, Zumerle said that there was a new method introduced with Android 4.4 (KitKat) called host-based card emulation, or HCE. With HCE, users no longer need the secure element (the external card) to conduct transactions via NFC. While this practice makes things more convenient for both the user and app providers, it obviously comes at the expense of security.
"Yes, HCE makes it less secure," says Zumerle. "When you remove hardware based security from the picture, that's always going to give attackers more ways to reach you."
Segmented devices, he explained, are the better solution. TIMA in Samsung's Knox security suite, for example, stores secure configuration volumes in a secure portion of the device's chip.
"During runtime, it compares the values of the secure section with the current values of the device, so if something changes, you can immediately kill the secure portion of the device," he says. "It's the same thing you can do with some access control or payment applications; if they've been tampered with, you can embed those controls and try to kill the application."
Some inherent risks still remain, however. After all, in a scenario with something like access control, there's nothing stopping attackers from just picking up an employee's phone -- in the event that it's lost or stolen -- and using it to swipe in.
"No, nothing prevents people from doing that," says Zumerle. "The device is enable to pair with the reader automatically. You would have to have some sort of combined set up; for example, no NFC if the device is locked. Some vendors do that, but it's at the expense of convenience. It all depends on how much risk an enterprise is willing to take."
Asrar adds that even though failsafes typically boil down to native security features of the platform (like device locking) they're often not implemented, so it's up to enterprises to roll out additional safety measures.
"A lot of people don't even have passcodes," says Asrar. "But there are additional wares out there like single sign on [for two-factor authentication] that can be tied into enterprises' deployments."
Ultimately, while both Zumerle and Asrar feel that there are certainly inherent risks, whether or not it's safe to use mobile devices for access control also depends on the context. As Zumerle points out, the practice forces people to rely on the hardware. But when they do that and want to account for the entire spectrum of mobile devices, it becomes more difficult since they are not all the same.
"Technically, if you have a solution that is set up with some security precautions, there are, today, the technological tools that make it so that it's something that enterprises could use," says Zumerle. "So yes, but it depends on the exact solution. Something well done can work, but you need to have the right measures in place. If you implement something that only works for a specific device or scenario -- like something that's good for a specific project -- and then you want to do something like BYOD, then it starts to get complicated."
The other side of the coin is that the threat landscape is constantly changing; the practice of using mobile credentials is only safe as long as the good guys can keep up.
"There are certainly major vulnerabilities, but we are tracking them on a day to day basis," says Asrar. "The problem is that it's like a cold war situation. The bad guys are constantly evolving and the security companies are also evolving, and we're trying to stay ahead of each other. It's an evolving field, so it's hard to say...we're focused on what was the vulnerability that got through. It really depends on that."
Also complicating matters is the fact that there are multiple ways in which mobile credentials are being used. Another popular use for storing one's credentials on a mobile device is banking and financial transactions, so it goes without saying that access control credentials aren't the only thing at risk.
To an extent, mobile wallets have some fail-safes built in to protect credentials. Some applications store the credentials on the device itself, but it's encrypted. Others, however, don't actually store users' banking information locally on the device.
"Some apps may have the ability to take the information and store it on the packet server, in case you're worried about the device going missing or getting stolen," says Asrar.
Similarly, banking credentials can be stored either in the cloud or on a secure element, much like access credentials. Even this approach, however, is not foolproof.
"[Storing information on the cloud] does ensure some security to some extent," says Asrar. "But it can be abused, and it comes down to what the transaction company has planned to protect users."
He adds that while security companies are constantly trying to determine which vulnerabilities were specifically targeted in these systems -- and subsequently patching them up -- consumers should also take basic steps to protect themselves. Security measures like installing anti-virus, immediately downloading updates, and not trying to bypass your company's security policies are all no-brainers.
While the banking data that the user enters can be secured in a number of ways, the actual application can be secured as well, says Zumerle. That way, attackers can't leverage it to fetch or record important data during transactions.
"There are certain methods you can deploy and there are vendors that supply solutions that you can embed into the app that have certain controls," says Zumerle. "For example, it can open the app in a sandbox for you and check to see if it is compromised. If it is, it will void the transaction or the application all together."
In a similarly preventative measure, many app developers are scrambling or encrypting their wallet apps before releasing them. This effectively prevents attackers from using reverse engineering to compromise software and re-releasing it to the public under the false pretense of it being a legitimate app.
"[Scrambling] makes the app harder to understand for an attacker, so it's not as easy to disassemble, reassemble with malicious content, and put on the app store for people to download and use," says Zumerle.
So on the device end of the transaction, there are ways that risks can be mitigated. But what about on the other end, at the point of sale?
"Well, you can put a reader on the terminal [to capture information]," says Zumerle. "And you can take advantage of an open connection during the transaction, but that starts becoming something like cyber pickpocketing that needs a physical presence and you have to do that in close proximity. In terms of POS risk, a rigged terminal is the greater concern."
Asrar, for his part, claims that McAfee has yet to come across a case of attackers nabbing credentials via NFC.
"We haven't come across a case, but it's not something that is far-fetched," he says. "There was a case a couple years ago where somebody uploaded an app that could read information from NFC communications, but it was for research purposes to show that it's a protocol and can be reverse engineered."
Even though it would appear that threats to the security of your mobile credentials can be found just about anywhere, Asrar says that users can still take simple steps to protect them from being compromised, including locking their devices and utilizing free security software.
"Even if users start using half of the features they have at their disposal," he says, "they will reduce the attack surface quite a bit."
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.