Phân tích chi tiết về các ứng dụng chat OTP Telegram và Signal: cách các hệ thống này như thế nào có thể đảm bảo tính riêng tư cho người dùng dưới góc nhìn kĩ thuật.

Kiến thức cần biết

  • symmetric encryption / asymmetric encryption. (mã hóa đối xứng / mã hóa bất đối xứng)
  • public key / private key
  • end-to-end encryption: toàn bộ tin nhắn giao tiếp giữa A và B được mã hóa, mà chỉ có thể A và B đọc được nội dung gốc (phía server cũng không thể đọc được)

Topic

Trình bày từng topic sau đây trên mỗi ứng dụng Signal và Telegram.

  • Giới thiệu: giới thiệu background của founder / các thông tin xung quanh (kĩ thuật) về ứng dụng.
  • Data storage: cách hệ thống đảm bảo data không bị compromise.
  • Infrastructure: cách hệ thống đảm bảo hệ thống đạt được high availability trong trường hợp bị chính phủ / cloud service provider chặn.
  • Single chat: giao tiếp giữa 2 người.
  • Group chat: giao tiếp giữa một nhóm nhiều hơn 2 người.
  • contact discovery: cách có thể nhận ra nếu một contact trong contact list có dùng Telegram.

Telegram

Introduction

Founder

  • Pavel Durov - người Nga.
  • 2007: sáng lập ra mạng xã hội VK (bắt chước theo Facebook)
  • 2011-2013: gặp các vấn đề về kiểm duyệt với chính quyền.
  • 2013: Sáng lập ra Telegram. Mục đích thiết kế một nền tảng chat an toàn cho người dùng, không bị chính quyền theo dõi.
  • 2015: Chuyển team qua Dubai để tránh các vấn đề kiểm duyệt. Theo như lời founder, sẽ tiếp tục thay đổi văn phòng công ty khi chính sách tại Dubai thay đổi.

Application

  • Như một mạng xã hội, mô hình “pull-based”
  • client-side open source. server-side close source. claims từ founder: không có giá trị khi open-source server-side, vì hoàn toàn server có thể thực thi phiên bản code khác với phiên bản open-source.
  • ứng dụng trên Android and iOS: reproducible builds. chúng ta có thể build lại bằng tay và so sánh nếu phiên bản binary down về trên mạng có khớp với phiên bản tự biên dịch hay không.

Infrastructure

Telegram theo mô hình client-server truyền thống. Tuy nhiên, Telegram đảm bảo (bằng văn bản)

  • Dữ liệu sẽ không được chia sẻ cho bên thứ ba, và Telegram sẽ không bao giờ đọc chúng.
  • Key sẽ được tách ra thành nhiều phần lưu trên nhiều datacenter → hạn chế bị compromise.
  • Data của người dùng sẽ được lưu trên nhiều data center trải đều nhiều quốc gia → nếu một chính phủ yêu cầu dữ liệu từ một người dùng sẽ rất khó.

Ý kiến trái chiều

Single Chat

Không phải end-to-end by default. có thể bật lên.

Câu hỏi: Nếu sử dụng end-to-end thì có an toàn không ?

Trả lời: an toàn. vì end-to-end + client-side open source.

Câu hỏi: Nếu không sử dụng end-to-end thì có an toàn không ?

Trả lời: Không. giữ liệu vẫn được lưu ở trên server Telegram và hoàn toàn có thể decrypt được.

Group chat

  • không có end-to-end encryption
  • tất cả data được lưu trên server và được mã hóa theo cách client-server-client
  • có thể phục hồi khi đổi thiết bị mới.

Question: Is this safe?

Answer: Theoretically, no. Telegram hoàn toàn có thể retrieve lại toàn bộ nội dung chat.

Contact Discovery

không có gì đặc biệt. Server lưu giữ hết mọi data, nên cách xử lí sẽ như mô hình client-server truyền thống.

Signal

Introduction

Founder

  • Moxie Marlinspike - computer security researcher . former head of security team at Twitter.
  • Publish many security vulnerabilities
  • Founder of Signal protocol: used in Signal / Whatsapp / Facebook Messenger / Skype
  • Sáng lập app Signal năm 2014

Application

  • fully open source: client side and server side.
  • Android and iOS applications are reproducible builds.
  • Đảm bảo không lưu trữ thông tin người dùng trên server (khác với Telegram). Đồng thời, thiết kế hệ thống với tiêu chị cho dù server bị compromise, thì dữ liệu người dùng cũng không bị ảnh hưởng.

Single Chat

  • end-to-end by default, and the only option.
  • Sử dụng safety number (a.k.a: fingerprint) để nói chuyện
  • Đảm bảo được 2 thuộc tính: Deniability + Forward Secrecy

0. Safety number

Tiếp cận cũ: sử dụng fingerprint (a.k.a: public key). Fingerprint là per-user. Tuy nhiên cách này có một số nhược điểm về UX

  • người dùng phải hiểu về cryptography.
  • việc verify fingerprint không dễ hiểu với người dùng cuối (chúng ta có tổng cộng 4 giá trị: (A và B’) (B và A’)
  • Public fingerprint nhiều nơi. Khi đổi điện thoại → fingerprint thay đổi → tạo ra confuse.

Tiếp cận mới: Safety number

  • Hash của A and B’s public key. Unique per conversation. (trước đó là per user)
  • Việc so sánh trở nên đơn giản hơn.
  • Advanced user: Có thể tách safety number ra trở lại thành 2 public keys. Điều này là cần thiết cho một số tình huống như A muốn verify fingerprint của B thông qua C.

References:

1. Deniability

Cần thỏa mãn 2 điều kiện:

  • Nếu một người nhận được một tin nhắn từ bạn, họ phải chắc chắn bạn là người gửi nó (chứ không phải là một bên thứ ba nào đó giả mạo).
  • Tuy nhiên, người nhận không thể chứng minh được với bên thứ ba là bạn là người gửi nó. Bằng cách này, người nhận không thể đi tố cáo với chính quyền (hoặc là bằng chứng trước tòa được).

So sánh với PGP signature (Pretty good signature): khi một người nhận được một PGP-signed message, có thể biết được chính xác ai là người tạo ra.

Cách PGP hoạt động

Cách đóng dấu điện tử một thông điệp

Trước khi trình bày rõ hơn thuật toán, ta sẽ đi qua 2 thuật toán tổng quát: thuật toán trao đổi khóa Diff-Hellman và thuật toán kiểm tra thông điệp MAC (Message Authentication Code)

Thuật toán trao đổi khóa Diff-Hellman

Là một thuật toán có thể an toàn gửi một cryptographic key qua một kênh công cộng (mà người trung gian trên đường truyền có thể đọc được) Tóm tắt

  • Bước 1: Trao đổi public key
    • Bob gửi cho Alice Bob’s public key (là giá trị ai cũng biết)
    • Alice gửi ngược lại cho Bob Alice’s public key (là giá trị ai cũng biết)
  • Bước 2: Tạo ra combine key
    • Bob: Bob private key + Alice public key → common key.
    • Alice: Alice private key + Bob public key → common key.

→ Do cách tạo common key buộc ít nhất phải có private key từ Alice hoặc Bob, do vậy, bất cứ ai trên đường truyền cũng không thể tạo ra được common key.

Hình vẽ khác mô phỏng lại thuật toán.

Lưu ý:

Khác với thuật toán RSA (được sử dụng trong SSL / HTTPS), thuật toán Diff-Hellman chỉ quy định về việc trao đổi key, nên hoàn toàn bị chịu tác động của man-in-middle.

A ↔︎ B ….. B ↔︎ C

Do vậy, vẫn cần thiết kiểm tra lại public key của bên mình nói chuyện có khớp không. (gọi điện / viết giấy / kiểm tra barcode …)

MAC - Message authentication code

Encryption chỉ đảm bảo được tính confidentiality, không đảm bảo được tính integrity. Tuy nhiên, ta thấy nếu attacker sửa đổi giá trị bất kì trên encrypted text, khi decrypt giá trị trở nên vô nghĩa. vậy tại sao chỉ dùng thuật toán encryption là chưa đủ ?

Lí do: Một số thuật toán cypher cho phép đổi giá trị trên một số bytes, do vậy nếu attacker đổi giá trị trên các bytes này thì ngữ nghĩa sẽ khác. Do vậy có 2 cách để khắc phục

  • Sử dụng lớp thuật toán “Authenticated encryption algorithm” : vừa encrypt và vừa authenticate. Ví dụ như OCB Mode hoặc GCM Mode
  • Sử dụng thêm thuật toán authenticate, ví dụ như HMAC. Sẽ có nhiều cách combine MAC + Encrypt (trình bày phần dưới). (Noted: HMAC có một bài toán khá thú vị tên là “timing attack”)

Sử dụng lớp thuật toán MAC đảm bảo được:

  • data integrity: dữ liệu chưa bị sửa đổi
  • authencity: ai là người gửi

Như đã trình bày, Có 3 cách để kết hợp việc sử dụng MAC và Encryption: Mac-then-Encrypt:

  • Compute the MAC on the clear text. append to data then encrypt as whole.
  • Used in TLS
  • Result: Encrypt(Message + Mac(message))

Encrypt-and-MAC:

  • computue MAC on the clear text. encrypt the clear text. and append MAC at the end of the cipher text.
  • Used in SSH
  • Result: Encrypt(Message) + Mac(Message)

Encrypt-then-MAC:

  • Encrypt the clear text. then compute the MAC on the cipher text.
  • Used in IPSec.
  • Result: Mac(Encrypt(Message))
  • theoretically better, but harder to make it right.

if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html

Moxie Marlinspike

Thuật toán Signal

  • Bước 1: Dùng thuật toán trao đổi khóa Diff-Hellman để tạo ra common secret
  • Bước 2: Dùng common secret để tạo ra các cặp key để giải mã việc gửi/nhận và các MAC keys
  • Bước 3: Dùng bộ key được tạo ra ở bước 2 để encrypt tin nhắn. Dùng MAC key được tạo ra ở bước 2 để tạo ra giá trị MAC cho tin nhắn. Và đồng thời gửi cả 2 giá trị này cho bên nhận.

Tại sao thuật toán lại đảm bảo được thuộc tính deniability?

  • Không thể đọc được: Do thuật toán được mã hóa bằng các cặp khóa gửi nhận, cho nên bất cứ ai đứng trên đường truyền cũng chỉ lấy được tin nhắn bị mã hóa (ngay cả Signal server).
  • Đảm bảo tin nhắn không thể bị giả mạo: Mỗi tin nhắn gửi đi bao gồm giá trị MAC, mà mục đích chính là để kiểm tra người gửi và tin nhắn có đúng không → không thể giả mạo.
  • Đảm bảo không định danh người gửi:
    • Ví dụ với giao thức PGP signature, chỉ có người nhận mới có thể gửi tin nhắn.
    • Ở giao thức Signal, bởi vì tập các khóa MAC được xây dựng từ shared secret, do vậy cả người nhận/người gửi đều có thể tạo ra một tin nhắn với cùng nội dung và MAC. Giả sử A và B nói chuyện, và B sau này khai báo chính quyền. Bằng một cách nào đó, chính quyền có cả private key của cả A và B, chính quyền cũng không thể chứng minh là tin nhắn đó A gửi (vì hoàn toàn B cũng có thể tạo ra một tin nhắn tương tự với cùng giá trị MAC).

Mở rộng: tại thời điểm bài blog được viết là 27/07/2013, Moxie đồng thời đưa ra một số nhược điểm và cách khắc phục.

2. Forward Secrecy

Tình huống đặt ra: Nếu ta chỉ sử dụng một khóa để encrypt mọi tin nhắn trong toàn bộ quá trình nói chuyện. Giả dụ chính quyền âm thầm lưu lại toàn bộ cuộc nói chuyện ( dù không hiểu). Trong một thời điểm ở tương lai, giả sử khóa hiện tại đang được sử dụng bị thỏa hiệp, chính quyền có thể đọc được toàn bộ tin nhắn từ đầu tới giờ.

Bài toán đặt ra: ta muốn giảm thiểu ảnh hưởng khi điều này xảy ra.

Cách khắc phục:

  • Sử dụng thuật toán Ephemeral Diffie-Hellman: liên tục thay đổi key (bằng cách 2 bên nói chuyện thay đổi số random đầu vào → tạo ra common key mới → xóa ngay 2 số random vừa tạo ra)
  • Piggyback quá trình Diffie-Hellman vào trong mỗi message gửi đi.

Do vậy, giả sử tại một thời điểm nào đó, key bất kì trên một thiết bị bị ăn cắp vẫn không thể giải mã các thông điệp trước đó.

Signal thậm chí còn mở rộng hơn nữa bằng cách khi chuyển qua dùng key mới, các bên sẽ public các MAC key cũ plaintext trên đường truyền. Bằng cách này, attacker có thể sửa đổi được text-đã-được-mã-hóa nhưng vẫn có giá trị MAC như cũ. Tuy nhiên, điều này càng chứng minh ai cũng có thể giả mạo được → dẫn đến tính ẩn danh càng tốt.

Giải thích:

  • Alice gửi một tin nhắn. Đồng thời kèm theo một khóa Diffie-Hellman mà Alice sử dụng trong tương lai.
  • Bob khi nhận được, sẽ phản hồi đồng ý, đồng thời trả thêm một khóa Diffie-Hellman mà Bob sẽ sử dụng trong tương lai.
  • Alice khi nhận được ack, sẽ bắt đầu sử dụng khóa mới. (và xóa đi khóa cũ trong hệ thống)

References Signal Blog

Others:

Group Communication

Introduction

  • Giao tiếp giữa một nhóm người
  • Signal không giữ các thông tin về group metadata: danh sách thành viên / group avatar / group title /…
  • Khi một người mới join một group đã có sẵn, người mới đó không thể thấy được các tin nhắn cũ.

Design

Design consideration: Đảm bảo được 2 thuộc tính của private chat: deniability và forward secrecy

Đồng thời phải đảm bảo thêm thuộc tính transcript consistency: đảm bảo toàn bộ thành viên của group đều thấy được cùng một nội dung message, và loại bỏ trường hợp tin nhắn được gửi riêng / thay đổi order / hoặc nội dung cho một số người chỉ định.

Zero-knowledge Proof

Scenario: Có một cánh cửa để mở ra kết nối 2 đường hầm, và cần có mật khẩu. Victor (aka: Verfier) muốn verify Peggy (aka: Prover) có biết mật khẩu không, nhưng Peggy đồng thời không muốn nói ra mật khẩu cho Victor nghe.

Step 1: Victor sẽ đứng đợi ở cửa hầm. Đợi cho Peggy đi vào và chọn một trong 2 lối A và B.

Step 2: Victor đi vào và hét to lên cánh cửa mà muốn Peggy đi ra.

Step 3: Peggy sẽ đi ra cánh cửa mà Victor hét to lên. Nếu Peggy đi vào cánh cửa B, thì sẽ cần dùng mật khẩu để mở cửa và đi ra cánh cửa A.

Ta nhận thấy:

  • Nếu Victor đi vào và chọn ngẫu nhiên A hoặc B, nếu Peggy không biết password, xác suất mà Peggy chọn ngẫu nhiên cánh cửa ban đầu mà trúng là 50%.
  • Nếu Victor và Peggy làm vậy liên tục 20 lần, và Peggy vẫn ra đúng cánh cửa, thì xác suất rất cao là Peggy biết password mở cánh cửa.

Những bài toán tương tự:

  • A đưa ra một ô sodoku và muốn B giải được. Làm sao B chứng minh là mình giải được mà không tiết lộ thông tin về các ô đã được giải ?
  • A và B cũng đang giữ 2 giá trị X và Y tương ứng. Làm sao để verify 2 giá trị X và Y có bằng nhau hay không mà không tiết lộ thông tin về giá trị.

How Signal group works?

unecrypted message sending flow

ecrypted message sending flow

Signal sẽ coi việc group chat như là chat 1-1 giữa nhiều người. Điều này mang lại 2 điểm mạnh

  • Tận dụng các ưu thế đã phát triển cho việc giao tiếp 1-1
  • Signal không aware về group chat, do vậy đảm bảo được quyền riêng tư

Tuy nhiên, điểm yếu như ta thấy là ta chọn mô hình fan-out ở client, dẫn đến client phải gửi nhiều request (tuy nhiên, điều này có thể không phải là vấn đề trên thực tế)

Cách Signal quản lí group metadata

Ở mô hình cũ, Signal không lưu trữ bất kì thông tin gì về group’s metadata. Do vậy tạo ra một số nhược điểm:

  • Không thể thiết kế hệ thống phân quyền. (các user có thể tự claim những quyền không thuộc về user đó). Do vậy, cách đơn giản nhất để thiết kế là các user trong cùng group đều có quyền ngang nhau: đều có quyền thêm và xóa các thành viên trong group (về bản chất là tạo ra một group mới).
  • Khi 2 user cùng update trên cùng một số data, sẽ tạo ra race condition. Do vậy, phải phát triển một hệ thống consensus giữa các client để giải quyết. Tuy nhiên, điều này là không khả thi trong mô hình asynchornous communication (khi một số device có thể offline trong session nói chuyện).

Tuy nhiên, Signal sau này cập nhật lại, lưu trữ các thông tin này trên server, do vậy, group communication có những chức năng như những app messaging khác: group owner / avatar / … Vậy làm sao để Signal đảm bảo được tính riêng tư cho người dùng ?

Group’s metadata được lưu giữ mã hóa trên server bằng GroupMasterKey.

id group_name avatar members welcome_message
765 “E2jP6c8LBAZFj2so8s=” encrypted-file “2wb5fLpn1yf566” “uJjNnyiPnMmfFtXpMkhFA/vYZWBkfTJvIw/jpy4+s”
766 “vNea+GD5b2lrikq6vY=” encrypted-file “Y+bt/qjxu8PlIH” “hKSQ2HnaCuvJXwjIq+U9cQ=”
767 “dil09QiiG6VZnk6eSE=” encrypted-file “+v2Hh1Sh0XuhrN” “L+88zl5ojqAksXtNmoxyCdAi/PeJS”

Alice là thành viên của nhóm, do vậy có GroupMasterKey (chỉ có thành viên của group có, Signal không có được). Alice sẽ gọi lên server để lấy data về.

Câu hỏi: Làm sao Alice có thể verify được mình là một member trong group, nhưng đồng thời không tiết lộ rõ thông tin bản thân?

Trả lời: Dùng Zero Knowledge Authentication như đã trình bày ở phần trên.

References:

Signal

Others: