Interaction diagrams are used in UML to describe how objects collaborate together[37]. The most common and intuitive interaction diagram is the sequence diagram. Sequence diagrams capture the behavior of a given scenario and are very useful for describing the message exchange in a system. Three sequence diagrams are presented showing the registration, key exchange and authentication scenario.
4.3.1 Registration
Figure 31 shows the registration of a new user. The registration is started when an unregistered user wants to use the mobile OTP solution for authentication. The user is asked to type in personal data and phone number. The data is relayed to the AS which checks that the phone number is valid and then stores the data in the user data base. A short password is created and exchanged with the user through the Internet browser. The user can now download and install the OTP MIDlet. When this is done the AS initializes an asymmetric key exchange to establish a strong shared key with the client.
Figure 31. Sequence Diagram – Registration
4.3.2 Key Exchange
The Simple Password Exponential Key Exchange (SPEKE) protocol [38] is used for the key exchange. SPEKE is an authenticated version of Diffie-Hellman (DH) [39] which prevents Man-In-The-Middle attacks by basing the DH generator on a hash of a shared password. An attacker who is able to read and modify all messages between the client and server cannot learn the shared key and cannot make more than one guess for the password in each interaction with a party that knows it.
The key exchange is shown in Figure 32 and as can be seen only two messages is necessary to complete the exchange. The parameters used in the key exchange are defined below
p– a large and randomly selected safe prime g – the Diffie-Hellman generator
π – short password shared between the client and server a – server private key
ka - server public key b – client private key kb- client public key k – shared secret key
The AS starts the key exchange by generating p. Based on p and a hash of π, g is calculated g = hash (π) 2 mod p
Then the AS computes a, which is a secret random integer. Now ka can be calculated ka = ga mod p
When this is done AS sends p and ka to the Authenticator. The Authenticator sends the values on to the client with an SMS. Upon receiving the SMS from the Authenticator the MIDlet is automatically launched and the user is asked to enter two passwords. The first password is a user chosen password used to ensure two-factor authentication. The second password is π and is used to authenticate the key exchange. π is displayed in the browser when the registration is completed.
When the user has entered the passwords the MIDlet retrieves p and ka from the SMS and calculates the same generator g as the AS.
g = hash (π) 2 mod p
Then the MIDlet generates a secret random integer to be used as band calculates the public key kb.
kb = gb mod p
When kb is calculated the MIDlet sends it back to the Authenticator and computes the shared secret key
k = (ks)b mod p.
When AS receives kb from the Authenticator it computes k = (kb)a mod p
Now the AS and the MIDlet shares a strong secret key k which can be used for generating the OTP.
The MIDlet completes the installation by encrypting the shared key with the user’s personal password and then storing both the encrypted key and a hash of the password in the phone’s memory.
When installation is complete the user can be authenticated by the mobile OTP solution.
Figure 32. Sequence Diagram - Key Exchange
4.3.3 Authentication
Figure 33 shows a successful authentication of a client using the mobile OTP solution. It is required that the user is already a registered user of the authentication service and that the OTP MIDlet is installed on the user’s mobile phone. The authentication is initiated when a user requests access to a service that requires authentication. The SP notifies the authenticator that a user needs to be authenticated. The session is redirected to the authenticator and the user is asked to enter a username. The username is sent to the AS which gets the secret key for this client and from this generates an OTP. The OTP is also based on a challenge. A different challenge is used every time so the generated OTP is always changing. At last a message authentication code (MAC) based on the secret key is calculated over the OTP. The AS sends the triplet (challenge, MAC, OTP) to the Authenticator which relays the challenge and the MAC to the client. Upon receiving the challenge the client calculates the OTP. Then it calculates the MAC and compares it to the one received from the Authenticator. If the values match the client can authenticate the AS since the AS has proved that it is in possession of the shared key. The client then sends the OTP back to the Authenticator. If the MAC is wrong the authentication is aborted. The Authenticator compares the OTP with the one received from the AS and if they match notifies the SP that the client is authenticated. A mutual authentication of the client and server has been achieved and the session is redirected back to the SP which grants the user access to the service.
Client Service Provider Authenticator Authentication Server
AccessService() User
StartAuthentication()
IdentityRequest()
IdentityResponse()
AuthenticateUser(Identity)
SMS(Challenge, MAC)
AuthTriplet(Challenge, MAC, OTP)
Response(OTP)
UserAuthenticated() AccessGranted
CompareOTP(OTP) Sequence Authentication
Figure 33. Sequence Diagram - Full authentication