SolidPass™

What is SolidPass?

SolidPass is Aradiom's on phone 2FA security product.

What OTP (One Time Password) generation methods does the SolidPass system offer?

• Time Based OTP Generation
• Challenge Response Based OTP
• Time and Challenge Response Based OTP Generation
• Challenge Response (with or without Time) Based OTP Generation with Security Question
• Challenge Response (with or without Time) Based OTP Generation with Transaction Signing
• Challenge Response (with or without Time) Based OTP Generation with Security Question and Transaction Signing

How does SolidPass™ guard against Trojans?

A Trojan attack cannot be executed even if a Trojan is installed on the phone because the client is built according MIDP2.0 specifications. The client stores the PIN in secure RMS storage, where access is denied to other applications.

How does SolidPass™ guard against a Stolen Phone?

The attacker cannot decrypt the private key without knowing the PIN. Even if the login credentials are known for online banking, the lack of a PIN will prevent any potential fraudulent transactions since a valid One Time Password ("OTP") cannot be generated without the PIN.

How does SolidPass™ guard against a Brute Force attack?

A Brute Force attack on the SolidPass™ Mobile Application is not feasible since mistyping the PIN 3 times in a row deletes all data from the phone and the user is then required to reactivate.

How does SolidPass™ guard against Compromised Midlet Download?

The user receives the SolidPass™ Mobile Application via WAP Push to his mobile phone. Theoretically, an attacker could convince the user to download and install a malicious application instead by sending an SMS that imitates the bank’s WAP push. This makes it possible to get the secret activation code, as the user, thinking he is using the SolidPass™ Mobile Application on his phone, enters his application code into a malicious application which transmits the code to the attacker. But even if the attacker receives the secret activation code in this manner, he still has no access to the user’s online banking login. Thus, compromising the midlet download may lead to a leakage of secret information used on the mobile phone, but nothing else. The security of the whole system is still not compromised because the attacker does not have the online banking login, which is the second authentication factor into the system.

How does SolidPass™ guard against Phishing Attacks?

A phishing attack occurs when the user (or the user’s computer) is tricked into thinking it is accessing the real web site, and enters credentials such as user name and password into a malicious web site. Using this technique, the attacker may get the login data to the online banking system. However, modified parameters or stolen credentials are useless with the use of the SolidPass™ System since the additional knowledge of the private data stored on the phone is required. There is a counter whose value is shared by the mobile phone application and the server. The challenge contains a cryptographically strong checksum which must match the counter value on the mobile phone within the given window. If the user is lured to a bogus web site, the counter value on the site will be out of sync with that of the mobile phone causing the attempt to fail.

How does SolidPass™ guard against MITM Attacks?

A man-in-the-middle ("MITM") attack is impossible since the challenge code given by the SolidPass™ System includes transaction specific data which is displayed to the user on the phone. The user then sees and validates the transaction.

Is it possible for a MITM attack to succeed against iTAN?

Yes. It was documented by RedTeam (‘If the computer system of the client is already compromised by a trojan or the user can be lured onto a phishing site, the (MITM attack) process can take place fully automated without any major drawback’)
http://www.redteam-pentesting.de/advisories/rt-sa-2005-014.txt
This allows an attacker to potentially divert funds to a fraudulent account.

How does SolidPass™ guard against Reverse Engineering?

To prevent successful reverse engineering attacks, a user should only be able to use the original mobile application downloaded from the bank. The SolidPass™ System includes verification of the original application, and only the original application will produce valid OTPs. A modified application made by a hacker does not contain the verification data and will always produce wrong codes. The hacker will not know the codes are wrong until they are rejected by the bank.

What handset devices are supported by Aradiom’s SolidPass™ Mobile Application?

Over 350 Java MIDP2 enabled mobile phones are tested and certified through Aradiom’s extensive internal QA process today. Aradiom constantly tests and certifies new phone models as they become available.

What is the minimum PIN length for SolidPass™?

The PIN is minimum 6 numeric digits, but it can be customized to require up to a theoretical maximum of 256. It is expected that most banks will want 6 digits for their deployments.

Can the SolidPass™ Mobile Application be built into Aradiom’s Java ME based mobile banking solution?

Yes. The SolidPass™ Mobile Application can be easily deployed with Aradiom’s QuickBank solution.

Is there a hardware module in the mobile phone for SolidPass™?

No, this is a software only solution designed to run on any Java MIDP 2.0 enabled phone, representing the majority of the world's phones today.

How can secret authentication information be securely stored on the phone with SolidPass™?

Neither the activation code nor the PIN are stored on the phone, thus securing this information.

Is SolidPass™ protected against viruses or malware on the phone?

To date, the mobile phone world has not been the victim of mass viral attacks such as in the PC world. This is due to several factors, one of them being the difficulty in getting one virus to run simultaneously on multiple phone operating systems and models.

Would a secure module in the phone make the solution even more secure?

When a user enters his PIN code into the SolidPass™ Mobile Application, the phone is activated. Even if there were an additional secure module, a rogue program on the phone could create signatures and perform other operations on the active module without the user noticing.

Are there any other countermeasures included to thwart the attacker?

Yes. If the attacker sets up a phishing web site giving random challenges, these will be detected by the SolidPass™ Mobile Application because of their incorrect checksum and warnings will be displayed to the mobile phone user.

How does the SolidPass™ Mobile Application compare to typical SMS based solutions?

Typical SMS based solutions involve sending OTPs from the bank to the phone via SMS. The user then enters the transmitted password into the online banking site to authorize a transaction. If the phone were stolen, the SMS messages could be compromised. SMS also does not provide guaranteed message delivery, so SMS messages can be lost or delayed. This reduces the reliability of SMS based solutions. Latency issues also arise during peak usage periods. Additionally SMS is insecure, in that messages are not encrypted and ultimately pass through vendor SMS gateways, which, if compromised, would allow an attacker to intercept OTPs sent via SMS. Also, SMS gateways can also be expensive and cumbersome to manage.

How does the issuing institution ensure that only registered users receive valid copies of the SolidPass™ Mobile Application?

The issuing institution must have the correct mobile phone number of the user receiving the SolidPass™ Mobile Application. The SolidPass™ Server generates a specific client application which is bundled with the unique application key, and sent to the phone via WAP push. An activation code is delivered to the user via another channel (often online or through the mail).

How does the issuing institution deliver the application to the required users?

Application delivery is initiated with a WAP Push message sent by the Application Download Server to the user’s registered phone number.

What security measures prevent keylogger attacks against the SolidPass™ Mobile Application?

Mobile phone manufacturers are making progress in providing open yet secure operating systems. Since Aradiom’s SolidPass™ Mobile Application is built on 2 factor security, key logging (for capturing the PIN) does not succeed in stealing identities. It should be noted that if a keylogger application is installed on a phone, the hardware based protection in the phone is just as vulnerable as a software solution. Remote control applications may work on certain phone platforms, and allow access to the user interface remotely, but usually not without being detected by the user.

What security measures prevent a second cell phone owner from using the SolidPass™ Mobile Application assigned to the original or previous phone owner?

The shared secret embedded in the application is invalid as soon as the original user activates a new copy of the SolidPass™ Mobile Application on a new phone.

Can a hacker who has the SolidPass™ Mobile Application reengineer it to produce one with challenges matching transactions he might have altered?

Only the original application downloaded from the bank can be used with the SolidPass™ System. To ensure this, the SolidPass™ System provides personalization of each copy of the SolidPass™ Mobile Application.

Can a hacker compromise the SolidPass™ Mobile Application to display what he wants?

As with any security system reverse engineering and building modifications are difficult but not impossible. However, without the personalization data embedded in the legitimate version of the application, the modified version is useless for use within the SolidPass™ System.

Is there a secure hardware module in the mobile phone for SolidPass™?

No, this is a software only solution, designed to run on any Java-enabled phone.

How can secret authentication information be securely stored on the phone?

Secret authentication information is derived from the activation code and the unique code that is sent with the application by the issuing bank. The resulting code is encrypted using the user’s own defined PIN, which is defined on first use. Neither the activation code nor the PIN are stored in the phone.

Isn’t this less secure than using a secure hardware module, such as a smart card?

No. The security models of these two schemes are quite different. With SolidPass™, the user interface and token are under the control of the user. With a smart card, the keys are safe within the token but the user has little control over the user interface. An untrusted terminal can generate any number of signatures for any kind of transaction and is therefore open to attack. For example, after the user has entered his smart card and PIN code into an untrusted terminal device, the device can generate any number of signatures for any kinds of transactions without the user having any control over this. The mobile device, which is in the users own possession, can be considered a trusted device.

Is it possible for someone that has gained possession of the phone to crack the owner’s PIN?

The token does not directly indicate to the user if the entered PIN was correct. Instead, it generates a response based on the PIN supplied by the user (in this case the attacker) which has to be keyed in to the service used (e.g. web-based Internet banking service) in order to check its validity. When the server sees too many invalid responses, it will lock the account.

Can the user still use the token if it is out of sync with the server?

Yes, but the software needs to be reactivated if the counter is off by more than the time window size defined by the system administrator. This would necessitate re-issue of the activation code to the user by the bank.

Are there any other countermeasures included to thwart the attacker?

Yes. If the attacker just sets up a phishing web site giving random challenges, these will be detected by the mobile token from their incorrect checksum and warnings will be displayed to the mobile phone user.

Is 2FA software token solution stronger than hardware tokens? What are their strengths and weaknesses in comparison?

The window of opportunity for a thief to use a mobile phone is substantially less than for a soft token (you realize your phone is gone long before you miss your token). In addition, there are optional features of software tokens that do not exist on hardware tokens, such as the software token application can warn the user if the challenge code is coming from a fake website, and the software token application communicates transaction specific information to the user on their mobile phone, therefore the user knows exactly what is being authorized.

How does a customer request and receive the mobile banking application?

The customers can request the mobile banking application via bank’s website, call center, or an SMS message. The application delivery is initiated with a WAP Push message over the mobile phone network or Bluetooth server to the registered phone number.

How could SolidPass™ ensure against someone running 2FA remotely from another device (not a possibility now, but a possibility as phones improve) – backdoor into the phone, with a keystroke logger?

Mobile phone manufacturers are making progress in providing open yet secure operating systems. Since Aradiom’s 2FA solution is built on 2 factor security, key logging (for resolving the PIN) is not sufficient for identity theft. Remote control applications may work on certain phone platforms, and allow access to GUI remotely – but this is difficult to do without the legitimate user noticing, even if he/she has installed this application by accident. It should be noted that if a keylogger etc. is installed on the phone, then hardware based protection in the phone would be as vulnerable as a software solution.

How secure are the keyboard and display on a phone - what would a hacker have to do to gain control over either?

Mobile phone user interface should not be considered secure, and therefore a 2 factor solution like Aradiom’s SolidPass™ should be used.

In what language Aradiom SolidPass™ built in?

Aradiom SolidPass™is built in Java ME language. With Java ME, each program runs in its own restrictive "sandbox." This prevents the program from accessing the files or memory of another program or accessing the hardware of the device in the uncontrolled way. Until now no viruses or trojans have succeeded in bypassing Mobile Java Security.

How does the solution address the issue of the phone being passed on for secondhand use, once a new one is acquired?

Aradiom’s SolidPass™ 2FA solution is based on 2 factor security. The user of the passed-on phone is not able to (mis)use SolidPass™s 2FA application without a correct username and password. Also, the shared secret embedded in the application will become invalid as soon as the original user activates a new copy of the application in the new phone.

Can a hacker, who obtains the application, reengineer it to produce one with challenges matching transactions he might have altered?

Aradiom’s solution includes a unique UserID of each copy of the application. Only the originally obtained copy of the application will produce correct response codes for authentication of transactions. A modified version used by a hacker will not contain the needed personalization data and will always produce wrong codes, which the hacker will not know are wrong until rejected by the bank. After a configured limit of failed attempts, a fraud alert may be activated.

Can a hacker compromise the 2FA client to display what he wants?

Reverse engineering and building modifications are difficult but not impossible. However, without the personalization data are embedded in the legitimate version of the application, the modified version is useless.

How does a bank ensure that hackers do not build faked Internet banking sites, where the banks customers are downloading a “new version” of 2FA, which in reality is malware to compromise 2FA (e.g. a compromised 2FA client to show other transaction details)?

The fake “new version” would not contain the required personalization data, required to produce correct response codes needed to authenticate the transaction by the bank, so the fake version would be useless.

How is the solution for joint accounts (meaning more than one person is allowed to make transaction)?

A single instance of 2FA mobile application is linked to the credentials which were used when obtaining the application and the activation code for it. If several persons with different credentials are allowed to do transactions, then each of them will have an instance of 2FA application in their phones, linked to their credentials.

Is SolidPass™ limited to banking security?

No. SolidPass™ can be used in any high security environment where OTPs are needed including network access control (e.g. VPN tokens or cards). Enterprise security, intranet access, graded network security are all potential areas of use for SolidPass™.

What is mobile phone based Access Control?

Mobile phones, activated with a soft embedded token, can act as a card key, hard token or other access control devices to ensure secure entrance, document or archive access, or other types of access control. A soft token solution such as SolidPass™ can turn your mobile or land-line phone into a remote control for any secure entrance property. It provides convenient control of access to any security entrance building or estate, or for access to sensitive information or database.