The user will receive the challenge from the attacker. The computer/user/ME has no way to check that the received challenge was actually issued by the AS to provide authentication for the user’ s session. Believing that this challenge was intended for him the user will unblock OTP generation function by supplying the PIN to the ME, the OTP value will be generated and sent to AS. AS will check whether the received and self-generated OTP values match and will authenticate attacker. If a Bluetooth connection is used between the ME and the computer, it should be well protected. The attacker can authenticate to any service provider registered at the AS even without the user noticing it (unless the PIN is required to issue confirmation message), if the Client Authenticator AS Access Response/Identity Challenge (Internet channel) Access granted AuC Request/Identity Challenge OTP OTP (SMS channel) Success
53 Bluetooth security is compromised. OTP from SMS to PC Like the architecture with session-IDs, this architecture is based on the fact that a user is already authenticated with the GSM/UMTS network. Therefore, the authentication process consists of the steps that ascertain that the owner of the ME is the same user that controls the computer. Figure 126.96.36.199: OTP from SMS to PC authentication  Since the AS does the check, the user does not have to verify that session-IDs match as in the architecture with session-IDs. The Authenticator redirects the session to the AS. The AS generates an OTP based on the user’s identity by using a hash function. When the user receives an SMS with the OTP from the AS, the user enters the OTP value into the browser (can be done automatically via Bluetooth). Then the AS verifies whether the received value matches the sent value, authenticates the user, and redirects the browser back to the Authenticator. The automatic version of this scheme utilizes a Java applet on the computer to get the OTP from the SIM via SAP. The OTP SMS to PC scheme utilizes the fact that the user is already authenticated in the GSM/UMTS network. Thus, the AS needs to confirm that the owner of the ME actually controls the computer. This is done with an OTP exchange. Although the OTP value is sent to the user’s ME via the SMS channel, it is not used to provide mutual authentication. The only difference between the randomly generated sessionID that could be used and the OTP value is that the latest is actually associated with the HTTP session created by the user . To do session hijacking the attacker needs to send OTP value from his computer. However, the attacker cannot intercept this value on the radio channel since this link is protected by GSM/UMTS security mechanisms. Only if Bluetooth is used between the ME and the computer can the attacker obtain OTP value by compromising the Bluetooth security. Though there is no need for the attacker to do this. By intercepting the OTP value, sent back to the AS via Internet channel, and sending it from his computer attacker can hijack the session. Since the OTP value
You've reached the end of your free preview.
Want to read all 104 pages?
- Spring '14
- ........., smart card, Two-factor authentication, Authentication methods