Authentication is a fundamental issue in computer security. Often it is solved with the use of passwords. Authentication can be a local process where a user authenticates himself to (a program on a) computer he has physical access to. With internet services users have to be able to authenticate themselves from their own PC to a remote server: remote authentication.
Remote authentication is more vulnerable to attacks than traditional authentic- ation, not just because authentication parameters are exchanged over an untrusted connection (usually remedied by a secure pipe over the connection), but also because the attacker does not need to be in physical proximity of the authenticating party, making attacks easier to perform. Furthermore, remote authentication may be vul- nerable to Man-in-the-Middle attacks, especially since these attacks can be employed at the user end point of a secured connection (e.g. in the case of a Man-in-the-Browser attack [91]).
Authentication is usually meant to define a process of proving or verifying one’s identity. But apart from this notion of user authentication, we also consider the notion of transaction authentication, where we not only authenticate a user, but also check that user’s intent in agreeing to some transaction, e.g. an online bank transfer. Transaction authentication is a form of non-repudiation, and typically subsumes a form of user authentication.
7.2 On (remote) authentication
In remote multi-factor authentication, the user will usually have a device as an additional factor. In order to restrict the use of this device to a specific user, such a device will often authenticate the user, before performing the authentication calcu- lations as the additional factor in remote authentication. This separate user authen- tication step is in itself an (assumed) part of the remote authentication. To prevent confusion, we will refer to this authentication step as local authentication. Also, we use the term “authentication,” to refer to both user and transaction authentication.
7.2.1
ECB’s notion of strong authentication
In January of 2013 the European Central Bank (ECB) published its’ recommendations for the security of internet payments [50]. These recommendations are the first res- ult of the European Forum on the Security of Retail Payments (SecuRe Pay), a volun- tary cooperation initiative including most European central banking authorities. The members of SecuRe Pay have committed to supporting the implementation of the re- commendations in their respective jurisdictions and will integrate them in existing supervisory/oversight frameworks. The recommendations should be implemented by payment service providers (PSPs) and Governance Authorities (GAs) of payment schemes by 1 February 2015.
The recommendations provide interesting key considerations and best practises for online authentication. In particular, it defines a notion of strong user authentication, which is defined as: “a procedure based on the use of two or more of the following elements:”
1. knowledge, something the user knows, such as a PIN; 2. ownership, something the user has, such as a smart card;
3. inherence, something the user is, e.g. biometric characteristics, such as a finger print.
This definition seems a pretty straight forward definition of multi-factor authentic- ation, but it adds additional demands: “the elements selected must be mutually in- dependent, i.e. the breach of one does not compromise the other(s). At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the internet. The strong authentica- tion procedure should be designed in such a way as to protect the confidentiality of the authentication data.”
This notion of strong authentication is only defined for online banking and has no legal status (yet). It does provide a starting point for strong authentication that we can use for other authentication problems besides online banking.
Regrettably, the ECB’s notion of strong user authentication only concerns authen- tication of the user, not authentication of transactions carried out by that user. A no- tion of transaction authentication is only considered in Best Practice 7.3 in the ECB re- commendations as an optional extra: “Strong user authentication could[our emphasis] include elements linking the authentication to a specific amount or payee.”
There is also some haziness in the ECB’s definition where it states that at least one element should not be capable of being surreptitiously stolen via the internet. Exactly
which attacks should be protected against by this remark? Simple eavesdropping of HTTP traffic? Or also attacks that use fake bank-sites or even Man-in-the-Browser attacks?
7.2.2
Multi-factor authentication using mobile phones
Multi-factor authentication is an often used technique to add security to authentic- ation. Often “Something the user has” is used as a second factor in authentication, particularly for remote authentication. This “something” the user has can be a hard- ware token, such as a smart card, an RSA token, or a passport. Especially with con- sumer services, the mobile phone is a popular device to use for this. Naturally, this assumes the user does not already use the phone itself to access the service he wants to authenticate to, since then it would no longer count as a second factor.
Mobile phones are a convenient choice for an additional authentication factor since practically all users carry a phone anyway. This both saves the costs of creat- ing dedicated tokens and saves users from having to take care of an additional device. Furthermore, because of the many uses a mobile phone offers, users (or at least smart phone users) typically check their phones 150 times a day [119], which results in users noticing the absence of their phones (e.g. through loss or theft) much faster than other hardware tokens. Also, phones have their own connections to the mobile network or the internet. So when using a computer for remote authentication, using a mobile phone as an additional factor automatically provides a separate path to the user. If, for instance, the computer is infected with malware, than this separate path to the user would remain uninfluenced by the malware.
Let’s take a closer look at some solutions for multi-factor authentication using mo- bile phones: SMS mTAN, Google Authenticator, the Twitter app, Mobile PKI, tiqr and Cronto. In this discussion we assume that a user logs in to a server using a computer and uses the provided authentication methods on a phone as an additional authen- tication step.
SMS mTAN / OTP
A TAN, Transaction Authentication Number, is a code used to authenticate a transac- tion. Originally, some banks gave lists of TANs to customers which could be used as one-time passwords, to authenticate themselves or to authorise transactions. Sev- eral banks now use TAN codes transmitted to the user’s mobile phone via SMS for authenticating online banking transactions. These codes are often referred to as “mo- bile TAN” (SMS mTAN), or as SMS One-Time Password (SMS-OTP) [123]. Note that these two names allude to the two different forms of authentication we distinguish, namely transaction authentication for TAN and user authentication for OTP. With SMS mTAN/OTP the user receives a code via SMS message and enters this code unaltered into his computer (the challenge and response are equal).
SMS mTAN is usable on practically every mobile phone since it only needs a work- ing subscription for the mobile network to receive SMS messages. This option does not store secrets on the phone and the message size offered by SMS provides the pos- sibility to give the user additional information besides the mTAN, such as the receiv- ing account number and amount of money in a banking transaction. This allows a
7.2 On (remote) authentication
user to validate the transaction he is authenticating through an independent chan- nel, which is also called out-of-band verification.
A downside to SMS mTAN are the costs involved; every SMS / authentication costs money. Also, this approach is vulnerable to any attack which intercepts the SMS. There are several attacks to intercept SMS messages:
1. Eavesdropping the wireless link (as detailed in Chapter 3),
2. Malware on the phone which intercepts the message and forwards it to the at- tacker [73, 151], and:
3. SIM-fraud, where an attacker manages to obtain a new SIM card belonging to the phone number of the victim.
In each of these attacks an attacker obtains the TAN code and could use this to au- thenticate to the service assuming the attacker can already circumvent the other factors involved in authentication [123, 144]. In the first attack, eavesdropping, the victim will also receive the SMS message, which should alarm him if he did not re- quest the message. Alternatively, an attacker could use an active Man-in-the-Middle attack between the cell tower and the victim’s mobile phone and simply not trans- mitting the mTAN on to the victim (Section 3.2.2). In the other two attacks the SMS messages can remain hidden from the user, but in the third attack all telco services to the victim will be discontinued when the new SIM card is activated, which also makes this attack detectable. The malware attack is the attack which scales the best when performed on many targets, since the eavesdropping attack requires the attacker to be in the vicinity of the victim when performing the attack and the SIM-fraud attack requires the attacker to obtain a new SIM card from the victim’s provider.1
Finally, this authentication method is also vulnerable to a Man-in-the-Middle at- tack, where the user thinks he is performing a correct authentication, but the attacker modifies or redirects the authentication messages in order to authenticate on behalf of the victim. All the phone-based additional-factor authentication techniques dis- cussed here are vulnerable to such an attack, though some, like the SMS TAN version, still have a benefit because of the out-of-band verification information that can be ad- ded in the SMS message. A user can use this information to verify he is performing the expected transaction [144].
Google Authenticator
Google offers a two-factor authentication scheme for its services [87]. First a user au- thenticates using a user name and password combination, then the users provides an OTP generated on a smart phone app. This smart phone app, called the Google authenticator, is a personalised app containing a secret shared with the Google back- end. The app generates a new code every 30 seconds (each code remains valid for one minute), so the challenge consists of the current time and is never transmitted. This
1From personal experience we found that some banks have started protecting against this attack through an agreement with the providers. The providers alert the bank when a new SIM card gets ac- tivated for a mobile number used for remote authentication to the bank. The bank then simply disallows any transaction from that phone number for a certain period, such as 48 hours.
is also called Time-based One-time Passwords (TOTP) [35]. The response is supplied by the user via the computer.
This time-based authenticator app runs on most smart phones and does not cost any money per authentication. It stores a secret within the app memory, which is not considered very secure. This secret is stored during the personalisation phase, by having the phone scan a QR code which contains the secret.
This additional authentication scheme is vulnerable to phone-side malware which either retrieves the stored secret or forwards authentication codes. If the stored secret ever gets retrieved by an attacker, while the victim remains owner of the phone, then the attacker can defeat the additional authentication step without the victim noticing this. As opposed to SMS mTAN, the Google Authenticator offers no out-of-band chan- nel through which a user can verify the transaction details he authenticates. This makes this authentication method extra vulnerable to a Man-in-the-Middle attack on the victim’s computer.
Twitter app
The Twitter app recently added a two-factor authentication option for users signing in via a PC [156]. The Twitter app itself also gives access to a user’s account, in which case it no longer counts as a second factor, but here we are interested in the use case of a user using the app solely as a second factor, while authenticating over a PC.
When a user enrols for this two-factor authentication, his app generates an RSA key pair en sends its public key to the Twitter server. Now, when a user tries to log-in to Twitter, the Twitter server will transmit log-in details (time, location and browser information) along with a random challenge to the Twitter app on the user’s phone. The app will notify the user of a log-in attempt, who can then approve or deny the action. Upon approving, the app will sign the challenge with its private key and send this back to the Twitter server as a response. After verifying the response the Twitter server allows the user’s PC to log-in.
This multi-factor authenticator runs on most smart phones, but will need an active data connection at the time of authentication. This authentication could cost the user money to transmit over a data network, especially when roaming abroad, though the amount of data transmitted is very small.
The app also provides the possibility to generate back-up codes for when the phone does not have a data connection. This is based on the S/KEY password sys- tem [93], which in turn is a concrete implementation of Lamport’s One-Time Pass- word scheme [114], where the app generates a secret and hashes thisntimes (in case of the Twitter appnstarts out at 10000) and sends this to the Twitter server during enrolment. Back-up codes are generated by hashing the secretn − 1times and dis- playing this to the user. The user can then type this code in his browser during au- thentication. The Twitter server then hashes the code once and verifies that it equals the value it stored during enrolment. Subsequently the server stores then − 1times hashed value and the app will generate ann−2times hashed value the next time, and so on. Effectively, this provides an OTP.
Both solutions were designed with the additional goal of the back-end server only being able to verify the authentication responses coming from the Twitter app, but not being able to generate said authentication responses itself. So, in the event of
7.2 On (remote) authentication
a breach of the back-end server (or at least the database containing the user log-in parameters) an attacker would still not be able to generate valid log-in responses on behalf of users [156]. Although this is an interesting feature, it does raise the ques- tion whether an attacker gaining access to the back-end of Twitter would not be able to then impersonate a user by other means, e.g. by changing the stored user log-in parameters to his own?
Both these solutions do have a secret stored in the app memory, which is con- sidered vulnerable. However, the benefit compared to the Google authenticator is that the Twitter server does not store the secret. Both of these Twitter app solutions are vulnerable to mobile malware, which can either retrieve the secrets or forward au- thentication codes. Again, malware on the PC is also a vulnerability, although the standard public key method of the Twitter app provides the user with out-of-band in- formation which he can use to verify he is logging in to the correct site.
Mobile PKI
Mobile PKI is an interesting variant where secrets are stored on the SIM2card [137]. It also makes an explicit separation between user authentication and transaction au- thentication. As the name suggests, this method relies on public key cryptography, where the SIM stores the user’s private key.
Mobile PKI uses the so-called SIM toolkit, an optional application on SIM cards with extensive additional functionality compared to normal SIM card applications. When supported by the mobile phone, the SIM Toolkit can perform actions such as sending SMS messages, or modify numbers called by the user. SIM Toolkit also al- lows for direct communication between provider and SIM card through service SMS messages, which are regular SMS messages with additional options set in the header indicating that the payload of these SMS messages are to be delivered directly to the SIM card, without notifying the user of the reception. These service messages are used in mobile PKI, where a message contains two data fields, one containing the data to be signed and one containing data to be displayed to the user. After reviewing the data displayed, the user can instruct the SIM card to proceed with signing. This will require an additional local authentication to the SIM card using a PIN code. When successful, the SIM card will sign the appropriate data and send it back to the server using service SMS messages.
Mobile PKI is the most costly of the techniques discussed in this section, since it both requires SIM cards that support Mobile PKI, which are not commonly provided to users, and requires SMS messages (both transmitting and receiving) per authen- tication. The use of the SIM card also involves an organisational hurdle, since the SIM card is under the sole control of a provider. This means that you both need the permission and cooperation of the provider, as well as have the required trust in the provider.
While it is possible to eavesdrop on the wireless transmission of the service SMS, this does not matter for the Mobile PKI solution. Not only can the contents of this message have extra encryption, the contents of these messages are useless to an at- tacker without access to the secrets stored in the SIM. After all, under the assumption
2We use the term SIM card, as this is the more commonly used term, though most modern phones ac- tually have a UICC with a (U)SIM application.
that challenges are not re-used, simply sniffing the challenge sent to the SIM card does not help an attacker and sniffing the response means the user already agreed to the authentication. The storage of secrets in the SIM is a huge security benefit com- pared to the other approaches since SIMs offer protected storage, which is not (yet) available in the phone memory.3
This approach is susceptible to malware attacks on the phone. Although the spe- cifications of SIM Toolkit require a phone to give sole control over the keyboard and