Presentation on theme: "XOTP: Mitigating Emerging Man-in-the- Middle Attacks with Wireless Hardware Tokens Assaf Ben-David, Omer Berkman, Yossi Matias, Sarvar Patel, Cem Paya,"— Presentation transcript:
XOTP: Mitigating Emerging Man-in-the- Middle Attacks with Wireless Hardware Tokens Assaf Ben-David, Omer Berkman, Yossi Matias, Sarvar Patel, Cem Paya, Moti Yung Google Inc.
Organization OTP – a hardware token OTP over Wireless Token/ Smartphone MITM review XOTP (Contextual OTP) Contexts realization against various MITM Extended attacks/ protections Conclusions
Known Example: OTP Device
OTP ( One Time Password) More than 500M phishing s are sent every day, getting user private information and their account passwords. OTPs are used to combat such (and other) attacks. However, OTPs can only mitigate off-line phishing. Indeed, 1/3 of the attacks on OTP-based systems use Man-in-the-Middle attacks: Passwords and OTPs are phished and used in real time.
OTP hardware token vs. Smartphone Whatever is computed on the hw token can be done on the smartphone! Smartphone in has a general CPU/ OS (more attack vectors on it but can run flexible algorithms), and has additional channels: bluetooth, NFC, camera,
Adding Wireless to the equation Instead of an OTP token, phone (or other device) with app can generate the OTP. OTP value sent by bluetooth: So man to computer becomes device to computer This improves: o Usability: no need to type OTP o Security: can use a longer string as the OTP o Cost: no need for token Key Question: o What can further be achieved with minimum infrastructure changes by using wireless?
So: What about real-time MITM phishing? But solving MITM requires full PKI (folklore) o Adversary can always sit in the channel and play the two parties and gain access.....we want to prevent even relay attacks that the MITM understand.. o Above TRUE: for naked channel & authenticated parties but Internet channels have characteristics, SO KEY OBSERVATION: we should break the symmetry between Channel with and Channel without adversary in the middle
XOTP Add context which will change the session when adversary is in the middle Entangle the context into the cryptographic calculation of the OTP The result: Contextual OTP (XOTP)
OTP Protocol Symbols: o Key: Shared by client & server o Chal: Synchronized, non-secret, non-repeating (e.g., counter/time based) o PRF(key, data) o Supp: supplemental data (empty in most implementations), e.g., password, user name, Nonce The protocol: OTP = PRF(Key, Chal || Supp)
XOTP Protocol Additional symbol: o XF Sess : Contextual factor The ideal c ontextual factor satisfies: o Recognition: Both sides recognize the same XF Sess o Uniqueness: [XF Sess1 <> XF Sess2] if [Sess1 <> Sess2] The protocol: XOTP = PRF(Key, Chal || Supp || XF Sess )
Correctness OTP case: PRF(Key, Chal || Supp) o Key is shared, Chal is synchronized, Supp, if non- empty, is known to both sides (e.g., user name and Nonce are transmitted separately, password is known given the user name) XOTP case: PRF(Key, Chal || Supp || XF Sess ) o XF Sess is known to both parties from the recognition assumption. Thus in both cases, both sides compute the same result.
Security - OTP case Relay attack is possible: The MITM attacker gets the OTP (and password) from the user and is able to use them in real time to masquerade as the user with the server.
Security - XOTP case Denote: o Sess1: Session between client and attacker. o XOTP1: The XOTP sent to attacker by client. o Sess2: Session between attacker and server. o XOTP2: The XOTP expected by the server. o H: XOTP protocol history observed by the MITM attacker. So attacker knows H || Chal | Supp || XF Sess1 || XOTP1. XF Sess1 and all contextual factors in H are different from XF Sess2 (uniqueness). Since XOTP2 = PRF(Key,... || XF Sess2 ), we have by PRF security definition, that attacker has negligible probability of guessing/producing XOTP2.
Types of contextual factors URL Server certificate SSL/TLS Session key IP Time & location Combination of factors (BTW: We are not the first to use context in protocols etc., but we identify it explicitly and for the specific purpose).
MITM phishing attack using a different URL (most attacks) imply XF Sess1 diff from XF Sess2 and is thus foiled. URL may be used to encode additional information such as transaction data to be displayed on the device for user confirmation. URL
+DNS poisoning…. but use TLS What if attacker uses the server's URL and divert communication to attacker by contaminating DNS? o Here XF Sess1 = XF Sess2. o Still, the attack will be foiled if the session is secure (HTTPS) due to TLS envelopping context! assuming the attacker hasn't broken the server's private key. o Note: HTTPS doesn't help in the OTP case: Attacker gets OTP from user (on a secure or insecure channel) and relay to server on secure channel.
Foils the attacks which URL foils. Foils a fake server certificate attack: o Attacker "persuades" a CA to certify that an attacker's public key belongs to the server (e.g., DigiNotar case). o Attacker contaminates DNS entries. o Attacker uses fake certificate in its session with user. o The attack is foiled because XF Sess1 <> XF Sess2 Can be combined with URL to allow inclusion of transaction data. In general: Using several contextual factors gives their cummulative benefits. Server's certificate
Implementation details Assume contextual factor is URL Use a browser extension which communicates with device through bluetooth Extension adds itself to a page containing a specified string (say "XOTP") and waits for event (clicking a button or the XOTP field, page submission, etc.) Sends the URL to device and copies the received XOTP into a specified field. Submits page or wait for user (or code on page) to submit it later.
Protocol extensions Two-way-authentication: Having a shared secret allows to establish two way authentication where the server is also authenticated. The device can warn the user if the server hasn't authenticated.
Extended attacks Man in the Browser (MITB) Man in the Device (MITD)
Keyloggers: o The Bluetooth scheme is secure against keyloggers because the XOTP is not typed by the user. General MITB: o The system can be made secure against general MITB by adding transaction data into the XOTP computation (data as well as different XOTP steps should be tagged). o For each step: The device will verify the transaction data by checking its XOTP. Transaction data would be displayed on the device for user confirmation. Man-in-the-Browser (MITB)
Man-in-the-Device (MITD) Attacker will have access to the shared key. Alternatively, the attacker can use the device to get XOTP to any desirable URL. Still, without access to the additional factor (password) the attacker would not be able to complete the protocol. Demonstrates the importance of using strong first factor and of compartmentalism (separation of duties) (not used in MO-07).
Summary of results Attack typeFactor checked by serverTechnology Impersonation (different URL) URLSmart device Impersonation (same UTL) + DNS poisoning URL + HTTPSAs above Impersonation + DNS poisoning + fake cert URL + HTTPS + server's cert As above Impersonation + DNS poisoning + fake cert + simple XSS URL + HTTPS + server's cert + session key As above MalwareURL + HTTPS + transaction data + user confirmation on device to server smart device with input capability and display
Conclusion Known: OTP adds entropy. Here: we augment it with "added context" Strong enough to foil many MITM attacks !! It demonstrates: o Modern wireless tools can improve (with moderate cost) security tools. o More generally, the idea of adding contextual information to cryptographic computations may enhance the security of other protocols o In general, think outside the box: do not let accepted folklore get in your way!