XOTP:
Mitigating Emerging Man-in-theMiddle 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 emails 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:
Usability: no need to type OTP
o Security: can use a longer string as the OTP
o Cost: no need for token
o
•
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)
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.........
o
•
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:
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
o
•
The protocol:
OTP = PRF(Key, Chal || Supp)
XOTP Protocol
•
•
Additional symbol:
o
XFSess: Contextual factor
The ideal contextual factor satisfies:
Recognition: Both sides recognize the same XFSess
o Uniqueness: [XFSess1 <> XFSess2] if [Sess1 <> Sess2]
o
•
The protocol:
XOTP = PRF(Key, Chal || Supp || XFSess)
Correctness
•
OTP case: PRF(Key, Chal || Supp)
o
•
•
Key is shared, Chal is synchronized, Supp, if nonempty, 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 || XFSess)
o XFSess 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 || XFSess1 || XOTP1.
XFSess1 and all contextual factors in H are different from
XFSess2 (uniqueness).
Since XOTP2 = PRF(Key, ... || XFSess2), 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).
URL
•
•
MITM phishing attack using a different URL (most
attacks) imply XFSess1 diff from XFSess2 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.
+DNS poisoning…. but use TLS
•
What if attacker uses the server's URL and divert
communication to attacker by contaminating DNS?
o Here XFSess1 = XFSess2.
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.
•
•
Server's certificate
Foils the attacks which URL foils.
Foils a fake server certificate attack:
o
o
o
•
•
o
Attacker "persuades" a CA to certify that an
attacker's public key belongs to the server (e.g.,
DigiNotar case).
Attacker contaminates DNS entries.
Attacker uses fake certificate in its session with user.
The attack is foiled because XFSess1 <> XFSess2
Can be combined with URL to allow inclusion
of transaction data.
In general: Using several contextual factors
gives their cummulative benefits.
SSL/TLS session
•
•
•
key (or PRF of it)
Foils a simple XSS attack in which a
malicious JavaScript on the page sends the
XOTP to the attacker.
However, using the session key may
increase failure rate (when SSL/TLS session
is restarted/resynch).
Also, the XSS attack considered here is only
on the authentication protocol. There are
other ways in which malicious scripts may
abuse the session.
•
•
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)
•
Man-in-the-Browser (MITB)
Keyloggers:
o
•
The Bluetooth scheme is secure against keyloggers
because the XOTP is not typed by the user.
General MITB:
o
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).
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-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 type
Factor checked by server
Technology
Impersonation (different
URL)
URL
Smart device
Impersonation (same
UTL) + DNS poisoning
URL + HTTPS
As 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
Malware
URL + 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
o
o
Modern wireless tools can improve (with moderate
cost) security tools.
More generally, the idea of adding contextual
information to cryptographic computations may
enhance the security of other protocols
In general, think outside the box: do not let
“accepted folklore” get in your way!
Thanks!