Meeting #5.

1. Undercover communications
By Dennis Gamayunov
Feb 15, 2014

2. /whoami
Dennis Gamayunov
 Security researcher
 Network security over 10 years
 Interests: kittens and stuff
Work at . . .

3. A bit of history
• User communications:
– BBS – late 1970s
– SMTP – 1982
– IRC – 1988
– ICQ – 1996
• Crypto:
– PGP - 1991

4. Privacy issues
• Unencrypted – anyone accessing the network
may read the messages
• Unauthenticated – anyone may pretend to be
anyone else
• But… deniable

5. PGP
Install GnuPG, generate a pair of keys for yourself; a
"public key" and a "private key".
The private key is like a regular key. You will use it to
sign and decrypt your messages
You publish your public key by sending it to a PGP key
server on the Internet.
People who wish to send you private email use a copy
of your key to encrypt the message.
You keep the (private) key to yourself, so that only you
can open and read (and sign) the messages.

6. PGP WoT
• Anyone can upload keys to “Key Servers”- even fake keys
• Authenticity of this public key can be checked as
• If you can verify that a key belongs to its owner, you can
sign that key, indicating that you have verified ownership
• Identify voice
• If not known, any
one else could say he
is owner of key
Make a call
• Check key
properties
Visit him • Search for another
person who verify his
identity
WOT

7. Example WoT

8. Trolling WoT
would you sign this key?
pub 1024D/1B629B3D 2005-12-27
Key fingerprint = 965E F829 EA6C
9174 4B46 43E1 4513 9A86 1B62 9B3D
uid u1tr4 l4s3r
<seekrit@hax0r.com>
sub 2048g/1F8E2EEA 2005-12-27
what would you need to know before you did?

9. Trolling WoT
• OHM2013 talk on fake PGP identities
– https://www.eff.org/event/ohm2013-trolling-
web-trust
• Sample tool available:
https://github.com/micahflee/trollwot
– Add fake signatures to keys
– Brute force PGP key id (and fingerprint)
– Create fake identities for given names and e-mails
and build WoT for them

10. PGP issues
• Usability of public-key fingerprints
– Hard to remember and pronounce
• Pseudo-word fingerprints
https://github.com/trevp/keyname
• Fake WoTs
• Lack of forward secrecy
– Stolen keys break all security properties of past
messages

11. Target scenario
• Assumptions
– Alice and Bob both know how to use PGP
– They both know each other’s public keys
– They don’t want to hide the fact that they talked, just what they talked
about
The Internet
Alice
Bob
Bad Guys

12. Now bad guys act
• Bob’s computer is stolen by “bad guys”
– Criminals, competitors
– Subpoenaed by the FBI
• Or just broken into
– Virus, trojan, spyware, black bag job
• All his key material is recovered
– Oh no!
• Bad guys now can:
– Decrypt past messages
– Learn their content
– Learn that Alice sent them
• And have a mathematical proof they can show to anyone else
• How private is that?

13. Lots of PGP-based projects available
• PGP-powered e-mail
• IM clients:
– Jabber (Pidgin et al)
– ICQ/AIM
– Basically any IM may be a transport for PGP-MIME
• Even WoT implementations for the Web and
OpenSSH
– http://web.monkeysphere.info/

14. SILC
• Stands for Secure Internet Live
Conferencing.
• Designed as a secure
replacement for IRC (Internet
Relay Chat), released in 2000.
• Also has some features of
instant messaging.
• Stable implementations for
clients and servers are available.
(http://www.silcnet.org)

15. SILC protocol
• A server handles channel maintenance and
accepts connections from clients.
• A client connects to a server to join and part
channels.
• A channel is a group of clients that are in the
same conversation.
• No one outside a channel is supposed to be able
to listen in on the conversation.
• It is assumed that each client has already
established a session key with each server to
which it talks

16. Protocol description (Client)
• If entity A sends something to entity B in SILC, it is always encrypted with
the session key between A and B.
• A client initially connects to a server.
• A connected client can request to join a channel on a server.
• The client knows that it has joined the channel when it receives a channel
key from the server.
• Every time a client joins or parts a channel, a new channel key is
generated and distributed among the remaining channel members.
• Each channel message, instead of being with the session key, is encrypted
with the channel key. However, the packet header (which stores the
source and destination) is still encrypted with the session key.
• A client, when it parts a channel, notifies the server so that it may update
the channel roster and regenerate the channel key.

17. Protocol description (Server)
• A server, when it receives a join request for a channel from a
client, adds that client to the channel roster if it is not already
there.
• A server, when it receives a part request for a channel from a
client, removes that client from the channel roster if it is there.
• If the channel roster changes, a new session key is created
and distributed to all remaining clients in the channel roster.
• Whenever a message for a channel is received from a client of
which it is a member, it is broadcast to all clients in the
channel roster. (Only the header is reencrypted.)

18. Protocol example
C1 C2S
Connect
Connect
Join #silctalk
generated-silctalk-key(1)
{Message: “I’m all alone.”}(1)
{C1 message: “I’m all alone.”}(1)
Join #silctalk
generated-silctalk-key(2)
generated-silctalk-key(2)
{Message: “Sup C1.”}(2)
{C2 Message: “Sup C1.”}(2)
{C2 Message: “Sup C1.”}(2)
Part #silctalk
generated-silctalk-key(3)
Part #silctalk
You have joined channel #silctalk
C1: I’m all alone.
C2 has joined channel #silctalk
C2: Sup C1.
You have parted channel #silctalk
You have channel #silctalk
C2: Sup C1.
C1 has parted channel #silctalk
You have channel #silctalk

19. Forward secrecy
• SILC regenerates the channel key on each
part/leave
• Users may additionally negotiate static
permanent channel encryption key
– Channel messages not visible to the server
– Key management is hard

20. OTR
• Designed by cryptographers Ian Goldberg and
Nikita Borisov in 2004
• Key features in addition for common
encryption:
– Perfect forward secrecy
– Deniability

21. Real-life model for OTR: casual
conversations
• Alice and Bob talk in a room
• No one else can hear
– Unless being recorded
• No one else knows what they say
– Unless Alice or Bob tell them
• No one can prove what was said
– Not even Alice or Bob

22. Perfect Forward Secrecy
• Use a short-lived encryption key
• Encrypt your data with it
• Discard it after use
– Securely erase from memory
• Use long-term keys to help distribute &
authenticate the short-lived key

23. Repudiable Authentication
• Do not want digital signatures
– Leave non-repudiation for contracts, not
conversations
• Do want authentication
– Can’t maintain privacy if attackers can
impersonate friends
• Use Message Authentication Codes (MACs)

24. MAC Operation
Data
MAC
MAC
MK
Data MAC
MACMK =?
Alice
Bob

25. No Third-Party Proofs
• Shared key authentication
– Alice and Bob have same MK
– MK required to compute MAC
• Bob cannot prove that Alice generated the
MAC
– He could have done it, too
– Anyone who can verify can also forge

26. OTR Protocol phase 1: AKE
• Alice and Bob pick random x, y resp.
• A->B: gx, SignAlice(gx)
• B->A: gy, SignBob(gy)
• SS=gxy a shared secret
• Signatures authenticate the shared secret,
not content

27. OTR phase 2: Message Transmission
• Compute EK=Hash(SS), MK=Hash(EK)
• A->B: EncEK(M), MAC(EncEK(M),MK)
• Enc is symmetric encryption (AES)
• Bob verifies MAC using MK, decrypts M
using EK
• Confidentiality and authenticity is assured

28. OTR: re-keying
• Alice and Bob pick x’,y’
• A->B: gx’, MAC(gx’, MK)
• B->A: gy’, MAC(gy’, MK)
• SS’ = H(gx’y’)
• EK’ = H(SS’), MK’=H(EK’)
• Alice and Bob securely erase SS, x, y, and EK
– Perfect forward secrecy

29. OTR limitations
• Basically online
– Short re-key interval
– Designed for IM
• Basically one-to-one
– Deniable multy-party OTR is a challenge

30. mpOTR
• Multy-party Off-the-record
communications
• Protocol draft proposed by
Ian Goldberg et al in 2009
• Current development:
– https://moderncrypto.org/
mailman/listinfo/messaging
– http://lists.cypherpunks.ca/
mailman/listinfo/otr-dev
– http://mpotr.secsem.ru/
• Initial implementation
expected in 2014
• Channel establishment
– IRC, XMPP MUC
• Authentication and key
establishment
– Group DH
• Communication
– Preserving message
ordering and causation
• Shutdown
– Publishing ephemeral
keys

31. Other undercover options available
• TorChat
– Relies on TOR hidden services feature
• CryptoCat
– https://blog.crypto.cat/wp-
content/uploads/2012/11/Cryptocat-2-Pentest-
Report.pdf
– Now implements OTR, bundled as browser plugin
– Aims at mpOTR roadmap
• Gibberbot, TextSecure, Xabber – Android
• ChatSecure - iOS

32. Undercover communications
The end.