Presented a seminar on ‘Secure Instant Messaging’ – security aspects and IMKE protocol

1. SECURE INSTANT
MESSANGER SERVICE
By:-
Sagar Chordia 09005013
Aditya Gupta 09005017

2. Contents
 Introduction
 Instant Messaging
◦ Types of IM
◦ Security Solutions for IM
 Instant Messaging Key Exchange protocol
◦ Introduction
◦ Goals
◦ Protocol
◦ Advantages / disadvantages
 Conclusion
 References

3. Introduction
 The number of interested parties eager to
listen in on your online conversations, including
what you type through instant messaging, has
never been higher.
 Broadband providers and their business
partners are enthusiastically peeking into their
customers' conversations.
 In today’s competing world privacy and secrecy
are very necessary.

4. Instant Messaging
 From wikipedia : “Instant messaging (IM) is a
form of communication over the Internet, that
offers an instantaneous transmission of text-
based .messages from sender to receiver”.
 It is text-based, bi-directionally exchanged, and
happens in real-time.
 It differ from other technologies such as email
due to the perceived quasi-synchronicity of
the communications by the users.

5. Types of IM (1)
 P2P (peer to peer) model
◦ No central load
◦ Anonymity of users can pose security threat
Server
Client A Client B
Peer to peer model

6. Types of IM (2)
 Server-client model
◦ All messages pass through central server.
◦ There is heavy load on the server.
◦ Security policies can be implemented easily
Server
Client A Client B
Server-Client Model

7. Security in P2P
 Security is either credential based or
reputation based.
 Can be implemented either by
◦ Central server
 Relies heavily on point source
◦ Mutual peer information exchange
 Implemented via gossip algorithm

8. Security in Server-client
 Security in server-based methods is
credential based.
 The server verifies the client via a known
secret (password). Once authenticated
the client can communicate with other
clients.

9. Security Solutions for IM
 SSL/TLS-based enterprise products
◦ e.g.Yahoo! Business Messenger
 Anti-virus, firewall and IM gateway
solutions
◦ e.g. Norton, zonealarm
 Public key based client-only solutions
◦ e.g. GPG, IMSecure
 Independent secure IM protocols.
◦ E.g. SILC, SKE, IMKE

10. INSTANT MESSAGING KEY
EXCHANGE PROTOCOL
-A secure IM protocol

11. Introduction
 A protocol for strong authentication and
secure communications.
 It enables mutual strong authentication
between users and an IM server.
 It uses a memorable password and a
known server public key.

12. Introduction (contd.)
 IMKE provides security i.e.
◦ authentication,
◦ confidentiality and
◦ Integrity
for client-server and client-client IM
connections with repudiation.
 Message contents are not revealed to
server

13. IMKE Motivation
 Existing solutions have drawbacks
◦ SSL: relayed user messages are visible to IM
server
◦ client plug-ins: client-server messages are
plaintext
◦ secure protocols: not designed for integration
 Strong password protocols do not fit
◦ Efficiency
◦ simplicity

14. IMKE - Goals
 Mutual assurance of identity
 Secure communications
 Forward secrecy
 Repudiation
 Replay detection
◦ authentication phase
◦ text message / file transfers
 M. Mannan, P.C. van Oorschot, “A Protocol for Secure Public
Instant Messaging,” in Financial Cryptogra-phy and Data
Security 2006 (FC'06) , Feb. 27-Mar. 2 2006.

15. Terminology used in IMKE
Term Description
“Strong” pass- A passive or active attacker should be unable to gather
word protocol enough information to launch an offline dictionary
attack even if a relatively weak password is used.
Secure Communications where authentication, integrity and
communications confidentiality are achieved.
End-to-end Securing messages cryptographically across all points
Security between an originating user and the intended recipient.
Repudiation A way to ensure that the sender of a message can
(later) deny having sent it. Some believe this is
important for casual IM conversations.
Forward The property that the compromise of long-term keys
secrecy does not compromise previously established session
keys.

16. Notation used in IMKE
Terms Usage
A, B, S Two IM users and the IM server
IDA User ID of A (unique within the IM service domain)
PA Password shared by A and S
RA Random number generated by A.
fi One-way cryptographic hash functions.
{data}K Symmetric (secret-key) encryption of data using key K.
{data}EA Asymmetric (public-key) encryption of data using A’s public
key KUA.
KsAS Symmetric (s) session (encryption/decryption) key shared
by A and S.
m
K AS Symmetric MAC key shared by A and S (m is short for
MAC).
m
[X]AS MAC output of data X under key K AS.

17. IMKE – The protocol
 IMKE can be divided into three phases:
◦ Password Authentication Key Exchange (PAKE),
◦ Client-Server Communications and
◦ Client-Client Communications (Direct and Relayed)

18. Password Authentication Key
Exchange (1)
 Step 1:-
◦ A generates KUA, KRA and KAS and sends it to server
in following manner.
◦ Encrypts session key with server’s public key.
◦ A  S : IDA, {KAS}ES , {KUA, f1(PA)}KAS
 Step 2 :-
◦ Server calls f1(PA) independently from it database and
compares. If unmatched then drops session
◦ Server generates RS (nonce) . Encrypts it with public
key of A
◦ A  S : {RS }EA, {f2(PA)}KAS

19. Password Authentication Key
Exchange (2)
 Step 3:-
◦ A decrypts RS using its private key, independently
calculates f2(PA), if not same drops session. Sends
◦ A  S : f3(RS)
◦ S independently cal f3(Rs) if not same then drops
session.
 Once this 3-way handshake is done A and
S calculates their
◦ Session key KsAS = f4(KAS,RS) and
◦ MAC key KmAS = f5(RS,KAS).

20. Password Authentication Key
Exchange (3)

21. Client-Server Communication
 Successful registration in PAKE sets up
server-client session key.
 Use this key for further communication
to server
◦ A  S : {ClientDataA} KsAS, [ClientDataA]AS
◦ A  S : {ServerData}KsAS, [ServerData]AS

22. Client- Client Communication (1)
 Step 1 :-
◦ Get public key of others from server via client-server
communication as in B)
◦ A  S : {KUB, IDB} KsAS, [KUB, IDB]AS
◦ B  S : {KUA, IDA} KsBS, [KUA, IDA]BS
 Step 2 :-
◦ A generates a symmetric key, KAB and verifies it using
a challenge-response method:
◦ Encrypt with public key of B, also send encrypted
nonce
◦ A  B : {KAB}EB, {RA}KAB

23. Client- Client Communication (2)
 Step 3 :-
◦ B decrypts the message get KAB, it sends
response of the nonce and another challenge
◦ A  B : {RB}EA, { f6(RA) } KAB
 Step 4 :-
◦ A verifies RA by self calculating f6(RA) and if
matches it decrypts RB replies with :
◦ A  B : f7(RA,RB)

24. Client- Client Communication (3)
 Then A and B derive the
◦ session key KsAB = f8(KAB,RB) and
◦ MAC key KmAB = f9(RB,KAB)
 This KsAB, KmAB are private to 2 clients,
◦ Server can’t know these 2 values.
 A sends ClientDataA to B,
◦ A  B : {ClientDataA}KsAB, [ClientDataA]AB

25. Client- Client Communication (4)

26. IMKE- message summery (1)
Phase Message
Authentication A generates a dynamic public/private key pair.
and A, S authenticate each other using shared
Key Exchange password.
A, S establish a session key.
A’s public key is sent to and stored by S.
Public Key A communicates to S a desire to talk to B.
Distribution S forwards B’s public key to A (and A’s to B).
Session A, B authenticate each other using the
Key Transport received public keys.
A, B establish a session key.

27. IMKE – Advantages (1)
 IMKE enables private and secure
communications between two users who share
no authentication tokens, mediated by a server
on the Internet.
 The session key used for message encryption in
IMKE is derived from short-lived fresh secrets.
This provides the confidence of forward
secrecy to IMKE users.

28. IMKE – Advantages (2)
 IMKE allows authentication of exchanged
messages between two parties, and the sender
is able to repudiate a message.
 Also , IMKE users require no hardware tokens
or long-term user public keys to log in to the
IM server.
 Other Security Attributes of IMKE
◦ Chaining of Messages.
◦ Insider-Assisted Attacks
◦ Exposure of Secrets

29. IMKE – Security Analysis
 Formal proofs : not done
 BAN-like analysis (outline) : checked
 AVISPA protocol analysis tool : checked
◦ http://www.scs.carleton.ca/~mmannan/avispa-
imke/

30. IMKE - Attacks not addressed
 Keyloggers can collect passwords
 A false public key of S on client allows
offline dictionary attacks
 Malicious IM server may forward false
client public keys (MIM)
 IM worms

31. IMKE – Future Work
 Group-chat and chat-room are heavily
used features in IM. A future version of
IMKE would ideally accommodate these
features.
 An online server public key verification
method can also be added.
 Introducing methods to ensure human-in-
the-loop during login can stop automated
impersonation using compromised user
name and password.

32. IMKE - Conclusion
 Secure IM: becoming increasingly
important
 IMKE: simple, integratable
 Main lesson from IMKE implementation:
practical today

33. CONCLUSION

34. Application of Secure IM
 Secure Messaging is used in many
business areas with company-wide and
sensitive data exchanges.
 Financial institutions, insurance companies,
public services, health organizations and
service providers rely on the protection
by Secure Messaging.

35. Other Tools for security in IM
 Other tools for security other then
Encryption are
◦ Steganography : The means by which data can be hidden
within other more innocuous data
◦ Identity based networks : True identity based
networks replace the ability to remain anonymous and are
inherently more trustworthy
◦ Anonymized networks : In principle, a large number
of users running the same system, can have
communications routed between them in such a way that
it is very hard to detect what any complete message is,
which user sent it, and where it is ultimately going from or
to.

36. Other Related Topics
 Secure Group Communication
 Secure voice over Internet program
 Security of Short Message Service
 Security of Internet Relay Chat
 Security of group chat
 Security of chat rooms

37. References
 A Protocol for Secure Public Instant Messaging
◦ Mohammad Mannan and Paul C. van Oorschot
◦ users.encs.concordia.ca/~mmannan/publications/imke.pdf
 HIGH LEVEL DESIGN - SECURE INSTANT MESSENGER
◦ www.ccs.neu.edu/home/noubir/Courses/CSG254/S09/designs/hu
sky.pdf
 Instant Messaging in Java Made Easy: The Smack API
◦ http://today.java.net/pub/a/today/2006/10/05/instant-messaging-
for-jabber-with-smack.html#jabbering-online-the-basics-of-jabber
 The Design and Implementation of a Secure Instant
Messaging Key Exchange Protocol
◦ by Chung-Huang Yang * Tzong-Yih Kuo
◦ http://www.kc.org.tw/fleget/FileDownLoad.aspx?CDE=149
 Wikipedia
◦ www.wikipedia.org

38. THANK YOU !
Questions ?