MITMA Countermeasure Service

Description

The MITMA Countermeasure Service protects against man-in-the-middle attacks (MITMA).

Real-time MITMA involve an unauthorized computer between client and server. The client who wants for instance to open the website of a bank is redirected to the man-in-the-middle (MITM) computer without realizing this, for example through a previously received phishing e-mail. The MITM connects to the banking website as well. From now on, everything the server sends and the client sees or sends is compromised.

With a MITMA, the URL of the MITM server is displayed on the client side instead of the URL of the banking server. The displayed information is not secure, and the end-user may sign a transaction that is not the transaction they see or intend to process.

The MITMA Countermeasure Service combines the SSL public key and the OTP calculation so that the server can use its own public key to validate the OTP. The server’s certificate public key (end of Phase 2) comes from the server that initiates the current SSL session. The OTP contains information on the SSL session that has been opened. The server, prior to the authentication or signature verification, obtains its public key and will perform the same process. Then, it extracts the OTP out of the credentials and validates it, which will be successful only if the validating server is the same server that opened the SSL session during which the OTP was generated.

The MITMA Countermeasure Service can be used with the following authenticator applications:

• Digipass for Web
• Digipass 110
• Digipass SDK

Functionalities

The MITMA Countermeasure Service uses the following functionalities of Authentication Suite Server SDK:

• Password validation with enhanced security
• Signature validation with enhanced security
• Digipass static PIN management with enhanced security

Workflow

The MITMA Countermeasure Service workflow involves the following steps:

1. The user is redirected to the MITM server, assuming they are going to connect to a regular website, e.g. a banking website. A legitimate SSL session is established between the user browser and the MITM.

   1. The MITM connects to the banking website, establishes a legitimate SSL session, and is directed to the bank’s portal page.

   2. The MITM serves back the bank portal, acting as a bi-directional proxy, potentially changing HTML or JavaScript elements of the page.

2. Digipass applet establishes a new SSL session to the web server, which in this case is the MITM server. Out of the SSL session, the applet extracts the server’s public key.
3. Digipass generates the OTP: OTP=f(DPKey, Kp, Time, Challenge)
4. The MITM passes the OTP to the banking server for verification.
5. The web application extracts the public key from the MITM<->Bank SSL session and tries to validate it.
6. The OTP is refused because the public key of the banking server is different from the MITM’s one used locally by Digipass for the OTP generation.

Figure: MITMA countermeasure workflow