ADHOKSHAJ MISHRA

Thwarting The Surveillance in

Online Communication

Who am I?

Contributor to n|u

Head of R&D, Skarpsinne Labs, London, UK

I am a hobbyist programmer with some interest

in information security domain. My primary
areas of interest are cryptography and malware.

Blog: http://adhokshajmishraonline.in

Email: me@adhokshajmishraonline.in

Agenda

Crooked activities by government

Why counter-surveillance?

Common surveillance methods

Counter -surveillance and cryptography

Keeping your data safe

Secure authentication

Private messages (chats, calls etc...)

Countermeasures for counter-surveillance

Crooked Activities

PRISM Program from NSA

Attempt to backdoor LINUX kernel

Backdoor in hard disk firmware

SuperFish in recent Lenovo laptops

Cryptographic keys for SIM stolen by NSA for

mass spying without warrant or permission
Cryptographic backdoor in MS Windows

Why counter-surveillance?

Because crooked practices by governments and

companies is unacceptable.
To recover from the damage done by gov agencies
under name of surveillance.
To make a balance between surveillance efforts
and privacy protection efforts

Common surveillance methods

By tapping the wire

By exploiting 0-day vulnerabilities (Tailored
Access Operation)
By paying the big boys to put backdoor in
software (MS Windows)

By weakening the cryptography (Dual EC_DRBG)

And many more......

Counter-surveillance & Cryptography

Mathematics is our friend. Let us trust it.

NSA cannot break good cryptography.

Cryptography allows all sorts of cool stuff, like

communicating in such a way that nothing can be
proved :D
All you need some cryptography skills and some
programming skills to get the things done.

Keeping The Data Safe

Encrypting the files is not enough

Encrypted volume is not enough

Even hidden volume of TrueCrypt is not enough

Keeping The Data Safe (2)

Fill entire volume with output of a good

cryptographically secure pseudo-random bit
stream generator.
Create multiple encrypted file systems at
different offsets in same volume.
Every I/O action should modify slack space at
random locations in all the file systems, as well as
host volume.

Keeping The Data Safe (3)

Put some genuine looking data in one of the file

systems, and secret data in other. Keep good
balance between them.
Output of a good cryptosystem cannot be
distinguished from output of a good pseudorandom bit stream generator.
Claim the data to be just random stream. Proving
otherwise will be very difficult.

Secure Authentication

CA will protect you only from those it is not

willing to take money from.
Secure channel can be
mechanism used by Superfish.

intercepted

by

You can authenticate yourself without revealing

your password.
Time to move to crypto magic .

Secure Authentication (2)

Alice has a secret s which he wants to prove to

Bob.
Three values y, g, and p are shared. P is large
prime.
Also
g^s mod p = y
Alice will generate a random number r, and
calculate C = g^r mod p. C is sent to Bob.
Bob will request either r or (s + r) mod (p - 1)

Secure Authentication (3)

Verifying the knowledge

in case of r:
C = g^r mod p
in case of (s + r) mod (p -1)
g ^ ((s+r) mod (p-1)) mod p = C.y mod p
Repeat the request verification cycle multiple times.
Select the request randomly each time.
In all cases, only a random number is sent, therefore
no knowledge of secret is leaked.

Private Messaging
Desired properties:

Encryption

Authentication

Deniability

Perfect Forward Secrecy

Authentication in Private Messaging

Shared values: g and p. P is prime.

Bob
picks random value r(128 bits)
picks random value x (320 bits minimum)
Calculates
v1 = g ^ x mod p; A = AES(key = r, v1); H = Hash (v)
Sends A and H to Alice

Authentication in Private Messaging

Alice picks random value y (320 bits minimum)

Calculates v2 = g ^ y mod p
Sends v2 to Bob

Bob calculates s = v2 ^ x mod p

Hashes s in different ways to generate c, c', m1,
m1', m2, m2'. C, c' are AES keys, others are MAC
keys

Authentication in Private Messaging

Shared values: g and p. P is prime.

Bob
picks random value r(128 bits)
picks random value x (320 bits minimum)
Calculates
v1 = g ^ x mod p; A = AES(key = r, v1); H = Hash (v)
Sends A and H to Alice

Authentication in Private Messaging

Bob picks keyid_B, a serial number for his DH key

g ^ x mod p
Calculates
Mb = MAC(m1)(g^x, g^y, pub_B, keyid_B)
Xb = pub_B, keyid_B, sig(B, Mb)

Sends to Alice
r, AES(key=c, Xb), MAC(m2)(AES(key=c, Xb))

Authentication in Private Messaging

Alice uses r to decrypt A (received from Bob)

Verifies H by recalculating it

Calculates s = v1 ^ y mod p (s same as Bob)

Calculates AES and MAC keys from s (same as

Bob)

Uses m2 to verify MAC(m2)(AES(key=c, Xb))

Uses c to decrypt AES(key=c, Xb)

Authentication in Private Messaging

Calculates Mb, and verifies sig(B, Mb) using pub_B

Picks keyid_A, a serial number for his DH Key

Calculates
Ma = MAC(m1')(g^y, g^x, pub_A, keyid_A)
Xa = pub_A, keyid_A, sig(A, Ma)

Sends to Bob: AES(key=c', Xa), MAC(m2')

(AES(key=c', Xa))

Authentication in Private Messaging

Bob
uses m2' to verify MAC(m2')(AES(key=c', Xa))
uses c' to decrypt AES(key=c', Xa)
calculates Ma = MAC(m1')(g^y, g^x, pub_A,
keyid_A)
uses pub_A to verify sig(A, Ma)

Now Alice and Bob have s, pub_A and pub_B

Encryption in Private Messaging

Alice is assured that s is known by someone with

access to the private key corresponding to pub_B,
and similarly for Bob.
All messages are encrypted using symmetric
cipher with shared DH key as encryption key.
DH protocol is re-initiated to generate new key
for next message.

Authentication in Private Messaging

Alice and Bob know each others public key

Alice and Bob have one more shared secret s1.

To detect impersonation or MITM attack, public

key fingerprints as well as shared secret s1 can be
verified using secure authentication as
discussed previously.

Thank You

Got any questions?