2021-03-08-telegram-vs-signal.pdf
•
1 like•29 views
People are leaving WhatsApp for Signal and Telegram. Privacy becomes important more than ever. Have we ever stepped back and rethought carefully how these applications handle end-users’ privacy? Is that a myth; a promise; or back-up by some scientific evidence? How can we, as an end-user, can verify and make sure these claims? This presentation will explain the history of the development of Signal and Telegram; and how they handle user’s data privacy under the technical microscope. Prerequisites: Some fundamental knowledge about cryptography: symmetric encryption; asymmetric encryption; public key; private key;
Recommended
Recommended
More Related Content
More from Thao Huynh Quang
Recently uploaded
Recently uploaded (20)
2021-03-08-telegram-vs-signal.pdf
- 11. End-to-end encryption %!%!@%!!#!$ Bob Alice %!%!@%!!#!$ !$!!(($# !$!!(($# TLS / HTTPS TLS / HTTPS Bob’s private key Alice’s private key Information Leakage - Bob used Signal/Telegram/Facebook Messenger - Bob talks with Alice - Keys are compromised at some points in the future —> All previous conversations can be decrypted - Alice sold Bob to the government.
- 12. Structure - Background of founders and applications - Infrastructure - Private communication between 2 people - Group communication
- 13. Telegram
- 15. Application • Worked as a social network with pull-based model. • client-side open source. server-side close source. Claim from the founder: there is no point to open source the server side, because server can execute arbitrary code which is different from open-source version. • Android and iOS source: reproducible builds. also known as deterministic compilation, is a process of compiling software which ensures the resulting binary code can be reproduced. We can compare between manual-compiled binary version with website version to verify there is no single changes in the website version.
- 16. Infrastructure Telegram is traditional client-server side. All datas will be stored on the Telegram servers. However, Telegram guarantees (through their public records): - Data will not be shared for third parties, and Telegram will not ever read those data. - Encryption key will be divided into many parts stored on many datacenter -> hard to compromise when one server is hacked - End-user’s data will be divided and stored on many data center expands to many countries - A single government will harder to get end-user data because it needs to compromise between many countries.
- 18. Group Chat • No end-to-end encryption • All datas are encrypted on server and encrypted client-server-client • Can be restored on the new device Question: Is that safe to use Telegram group chat? Answer: No. Theoretically, Telegram can decrypt and retrieve all chat contents.
- 19. Signal
- 20. History Founder • Moxie Marlinspike - computer security researcher . Former head of security team at Twitter. • Publish many security vulnerabilities • Author of the Signal protocol: used in Signal / Whatsapp / Facebook Messenger / Skype • 2014: Founded Signal application • Secondary Security Screening Selection (SSSS)
- 21. Application • Fully open source: client side and server side. • Android and iOS applications are reproducible builds. • Does not store user’s information on server. • Design in mind: even if server is compromised, user’s data cannot be leaked.
- 23. Single private chat • end-to-end by default, and the only option. • Using safety number (a.k.a: f ingerprint) to identity • Guarantee 2 properties: Deniability + Forward Secrecy
- 24. Safety number Old approach: f ingerprint (a.k.a: public key) • Fingerprint is the identity per-user • User must know about the cryptography • Verify f ingerprint is not a trivial task for end-users
- 25. Safety number Old approach: f ingerprint (a.k.a: public key) • Fingerprint is the identity per-user • User must know about the cryptography • Verify f ingerprint is not a trivial task for end-users Your phone Your friend phone There are 4 combinations here ….
- 26. Safety number New approach: Safety number • Hash of A and B’s public key. Unique per conversation. (per-user before) • Compare easier • Interesting property: Even after hashing, A can verify with C that they communicate to a same person. A <-> B1 ?? B2 <-> C Your phone Your friend phone
- 29. Diff-Hellman Is a method of securely exchanging cryptographic keys over a public channel Step 1: Exchange public key • Bob sends to Alice Bob’s public key (public value everyone can get) • Alice sends to Bob Alice’s public key (public value everyone can get) Step 2: Combine keys to create a shared secret • Bob: Bob private key + Alice public key → common key. • Alice: Alice private key + Bob public key → common key. Because shared secret is created from at least Bob or Alice private key, no one on the connection can know the shared secret.
- 30. Diff-Hellman
- 32. Diff-Hellman Bob Alice Bob’s public key Mallory’s public key Mallory Alice’s public key Mallory’s public key When started the conversation, Bob and Alice must check each other public key (Image / video call / cold paper …) Your phone Your friend phone In Signal, we compare Safety Number
- 33. MAC - Message Authentication Code Encryption ensures the con fi dentiality, but not the integrity. Question: If an attacker changes any byte of encrypted text, decrypted value becomes useless. Why is encryption algorithm not enough? Answer: Some encryption algorithms allow to change some bytes, which can be used to change the semantic of the meaning. There are 2 possible ways to fi x • Using class of “Authenticated encryption algorithm”: encrypt and authenticate at the same time. Example: OCB Mode or GCM Mode • Using class of MAC algorithms for integrity and authentication. Example: HMAC
- 34. MAC - Message Authentication Code There are 3 ways to combine a MAC algorithm and Encryption algorithm Mac-then-Encrypt: • Compute the MAC on the clear text -> append MAC data to the encrypt value as whole. • Result: Encrypt(Message + Mac(message)) • Used in TLS Encrypt-and-MAC: • Compute MAC on the clear text -> encrypt the clear text -> append MAC at the end of the cipher text. • Result: Encrypt(Message) + Mac(Message) • Used in SSH Encrypt-then-MAC: • Encrypt the clear text -> compute the MAC on the cipher text. • Result: Mac(Encrypt(Message)) + Encrypt(Message) • Used in IPSec. —> Proved to be the best choice
- 36. Signal algorithm • Step 1: Using key-exchange algorithm Diff-Hellman to create a shared secret • Step 2: Using the shared secret to • derive a sending and receiving cipher key for each party, • a set of MAC keys for each party
- 37. Deniability Property 1: Security We use common shared secret, which is only known by 2 parties -> no other can decrypt messages Property 2: Integrity and authenticity We use MAC as the mechanism for integrity and authenticity Property 3: Deniability - For any message M, Bob and Alice can produce a same message with the same signature because they use the same key - Bob knew that he doesn’t create a message M, as the result, Alice did. - However, Bob cannot prove with any third party that Alice send that message because Bob has the ability to send a same message with the exact signature.
- 38. Forward Secrecy • Ephemeral Dif fi e-Hellman: periodically change key while communicating • Piggyback the Dif fi e-Hellman algorithm in each sent message
- 39. Group communication • Communicate between group of people • Due to the natural of end-to-end group communication, when a new comer joins an existing group, he cannot see old messages. • Actually when a new person joined a group, a new group is created.
- 40. Design Consideration • 2 properties of private chat: deniability and forward secrecy • Other interesting property transcript consistency: assurance that all members of a conversation are seeing the same message transcript Example: • Messages which are selectively delivered or re-ordered to only some members • Messages which contain different plaintext for different members. Example: Bob sends to the group: “Who wants to kill the president?” Except Alice, to whom Bob instead sends “Who wants to get some ice cream?” Alice responds “I do, how about this afternoon!”
- 41. Design • 2 properties of private chat: deniability and forward secrecy • Other interesting property transcript consistency: assurance that all members of a conversation are seeing the same message transcript Example: • Messages which are selectively delivered or re-ordered to only some members • Messages which contain different plaintext for different members. Example: Bob sends to the group: “Who wants to kill the president?” Except Alice, to whom Bob instead sends “Who wants to get some ice cream?” Alice responds “I do, how about this afternoon!”
- 42. Design Signal will treat group chat as 1-1 chat between multiple people • Keep all advantages of the developed private chat protocol • Signal doesn’t aware about the group -> maintain the secrecy about group membership unencrypted message sending f low Signal: fan-out model
- 43. Group metadata management At old design, Signal doesn’t store any information about group’s metadata. Disadvantages: - No role system: All users will have a same role in the group (because individual can claims they’re the group leader) - Update same resource (group information / avatar / …): race condition -> must developed an asynchronous communication consensus. Not a trivial task because some devices can go of fl ine at any time.
- 44. Group metadata management New version: Signal stored encrypted group information on server using MasterKey from clients. Question: All data are encrypted (even Signal doesn’t know), how can Signal authenticate users?
- 46. Zero knowledge proof Wrong solution: - Victor waits at the door, at check if Peggy can go from B -> A or A -> B - If Peggy can come out from the different path -> Peggy de f initely know the password. Problem: - If Victor brings the camera with him and record again the whole process. Anyone watch this video will de f initely know Peggy know the solution -> Not zero knowledge proof.
- 47. Zero knowledge proof Step 1: Peggy randomly takes either path A or B, while Victor waits outside
- 50. Zero knowledge proof We see that: • If Peggy doesn’t know the password, the probability that Peggy luckily choose the correct path that Victor will select later will be 50%. • If Victor and Peggy try again the test and Peggy still come out at the correct path. The probability is: 0.5*0.5=0.25 • Let say we try this for 20 times and Peggy always come out at the correct tunnel. The probability that Peggy doesn’t know the password is 0.5^20 = 0.000000953674316 -> Very small chance that Peggy doesn’t know the password to unlock the door. We can assume that Peggy actually know the password.
- 55. Zero knowledge proof Peggy Red-green colour-blind Victor Victor hides 2 balls again behind his back
- 58. Signal group metadata management Alice is the member of the group -> Alice has GroupMasterKey (Signal doesn’t hold this key). Alice will come to the server, using the Zero Knowledge Proof to prove with Signal server that Alice can decrypt this information without revealing any information about the group. Alice adds Bob to the group: She sends the server a new entry encrypting Bob’s UID. Alice also sends Bob the GroupMasterKey via an encrypted Signal message. Now that Bob is a member of the group, he’d like to learn who’s in the group. He can prove he is a member using his AuthCredential, then download all the entries and decrypt them with the GroupMasterKey. If he has been granted the appropriate role, Bob could also add Charlie to the group, just like Alice added him.
- 60. Bring home … - There are many considerate things in privacy than only end-to-end encryption - Don’t mess with end-users - We cannot easily switch to another chat platform :(
- 61. Q&A Session