Giải ngố Cryptography – Phần 3: Đảm bảo Confidentiality với Encryption và Diffie-Hellman Key Exchange Protocol

Tiếp theo nội dung Phần 2: Đảm bảo Integrity với Hashing Algorithm, kỳ này tôi sẽ tập trung vào vấn đề Confidentiality với Encryption (“Mã hóa”). Và như đã trình bày trong Phần 1: CIA có gì hot, đối với Encryption, có 2 phương án cơ bản được sử dụng bao gồm Symetric Encryption (mã hóa đối xứng) và Asymetric Encryption (mã hóa bất đối xứng).

Trong bài Giải ngố Blockchain – Phần 3: Nguyên lý cơ bản của Elliptic Curve Cryptography và vấn đề mã hóa, tôi đã có so sánh tóm lược về Symetric Encryption vs Asymetric Encryption để làm cơ sở giới thiệu về Elliptic Curve Cryptography. Tuy nhiên, để có thể trình bày một cách hệ thống, tôi sẽ nhắc lại nội dung đó ở đây trước khi đề cập các vấn đề chi tiết.

Thông số	Symmetric Encryption	Asymmetric Encryption
Sử dụng	Mã hóa và giải mã với cùng 1 Key (khóa)	Mã hóa và giải mã với 2 Key khác nhau (Public Key và Private Key) Bảo mật thông tin: Mã hóa bằng Public Key, giải mã bằng Private Key Chữ ký số: Mã hóa bằng Private Key, giải mã bằng Public Key
Tốc độ	Nhanh hơn Asymmetric Encryption	Chậm hơn Symmetric Encryption
Ưu điểm	Xử lý nhanh, ít tốn tài nguyên nên thuận tiện cho việc mã hóa lượng lớn thông tin	Giải quyết vấn đề bảo mật trong “key exchange” (trao đổi khóa) của Symmetric Encryption dựa trên nguyên lý của Diffie-Hellman (DH) key exchange algorithm
Nhược điểm	“Key    exchange” là tử huyệt của Symmetric Encryption vì không có cách nào để bảo đảm vấn đề bảo mật khi trao đổi khóa (lựa chọn giải pháp face-to-face giao khóa tận tay có tồn tại trên lý thuyết chứ làm thực tế thì bốc sh*t!)	Tốn nhiều tài nguyên và thời gian để xử lý hơn Symmetric Encryption. Do vậy thường chỉ dùng ở đoạn trao đổi khóa, sau đó thì hệ thống sẽ chuyển Symmetric Encryption với cái khóa mới được trao đổi cho nhanh, bổ rẻ
Đại diện	Advanced       Encryption Standard (AES)	Rivest–Shamir–Adleman (RSA) Elliptic Curve Cryptography (ECC)

Như vậy thông thường, Asymetric Encryption sẽ được sử dụng trước để hỗ trợ quá trình trao đổi khóa của Symetric Encryption. Sau đó Symetric Encryption key này sẽ được sẽ được sử dụng cho các quá trình mã hóa tiếp theo. Theo trình tự đó, tôi sẽ tập trung giới thiệu phần Asymetric Encryption trước khi đề cập các nội dung liên quan đến Symetric Encryption.

Trước khi đi vào chi tiết 2 đại diện RSA và ECC, hãy để tôi giới thiệu qua về một nhân vật cũng khá nổi tiếng có liên quan chặt chẽ đến chủ đề hôm này là Diffie-Hellman key exchange protocol.

#1 Diffie-Hellman key exchange protocol in a nutshell

#1.1 Sức mạnh của Diffie-Hellman key exchange protocol đến từ đâu

Diffie-Hellman (DH) protocol là key exchange algorithm (thuật toán trao đổi khóa) để trao đổi share secret nói chung. Nếu tính theo dòng lịch sử thì DH có thể được xem là anh cả vì RSA cũng được xây dựng dựa trên ý tưởng của DH (ECC thì hiển nhiên phải gọi DH là cụ tính theo thâm niên công tác).

Hiện có 25 DH Group, số càng cao thì càng bảo mật tuy nhiên thời gian xử lý cũng sẽ càng lâu. Ngoài ra, việc lựa chọn DH Group cũng tùy thuộc vào tình huống sử dụng chứ không phải bạn muốn chơi sao cũng được (ví dụ DH Group 5, 14, 19, 20 hoặc 24 dùng cho encryption/authentication algorithm với 128-bit key; DH Group 21 dùng cho encryption/authentication algorithm với 256-bit key hoặc cao hơn).

Xét về mặt bản chất, sức mạnh thật sự của DH đến từ một “chiêu thức” có tên gọi Discrete Logarithm Problem (DLP) (tạm dịch là vấn đề logarithm rời rạc). Đây là bài toán ngược của phép tính Modular Exponentiation (tương ứng với việc tìm c theo công thức: c = b^e mod m).

Ví dụ, với b = 5, e = 3 và m = 13 thì c sẽ được tính là: c = 5³ mod 13 = 125 mod 13 = 8

Và khi đó DLP là bài toán đi tìm e trong công thức c = b^e mod m khi biết c, b và m. DLP hiện được các bậc thầy toán học xác định là khó ăn – tức là chưa có thuật toán hiệu quả để tính toán và đây chính là cơ sở cho sức mạnh bảo mật của DH.

Lưu ý:

– Mod có nghĩa là lấy phần dư của phép chia

– Nếu theo đúng nguyên tắc bảo mật chuẩn “cmn” mực là “Trust No One” thì bạn sẽ cần chứng minh lại vấn đề toán học nói trên. Tuy nhiên vì nguồn lực thời gian có hạn nên tôi nghĩ thôi tạm thời tin mấy ông làm toán đi. Có gì mai mốt rảnh coi lại sau (câu này dịch ra tiếng Việt nghĩa là éo có rảnh để coi lại đâu).

#1.2 Cụ thể thì Diffie-Hellman key exchange protocol hoạt động thế nào

Xem xét giản lược để dễ hiểu, quá trình trao đổi khóa theo DH được mô tả như sau:

– Step 1: Alice chọn 1 số private a và số public p và g. Sau đó Alice gửi p và g sang cho Bob. Đồng thời lúc này Bob cũng sẽ chọn 1 số private b. Như vậy Alice sẽ có a là private, Bob sẽ có b là private;

– Step 2: Alice tính tiếp g^a mod p = A và gửi A sang cho Bob. Như vậy lúc này sẽ có p, g và A được public;

– Step 3: Đến phiên Bob tính tiếp g^b mod p = B và gửi B sang cho Alice. Như vậy lúc này sẽ có p, g, A và B được public;

– Step 4: Alice tính B^a mod p = s và Bob tính A^b mod p = s. Vì B^a mod p = A^b mod p  = s nên s sẽ là shared secret chỉ có Alice và Bob biết. Shared secret s sau đó có thể được sử dụng để tạo khóa nhằm mã hóa thông điệp chứa Symmetric Encryption Key cho các bước tiếp theo.

Để dễ hình dung bạn có thể xem cái ví dụ tính minh họa với các con số đơn giản như sau:

Lưu ý:

– p thực chất là large prime number;

– a, b là interger nằm trong khoảng [1, p-1];

– g là random interger (thực ra có quy luật để chọn g chứ không phải thích lấy sao cũng được nhưng tạm thời để nhẹ đầu để tôi bỏ qua mấy quy luật đó);

– Thuật toán nói trên rất hoàn hảo trừ một tử huyệt đó là “Làm sao Alice biết chắc Bob thật sự chính là Bob, cũng như ngược lại sao Bob biết Alice là hàng chính chủ chứ không phải fake?”. Tôi sẽ đề cập kỹ hơn vấn đề này ngay trong Mục 3;

#2 Diffie-Hellman và Perfect Forward Secrecy   

Ở đây tôi thấy có 1 câu hỏi cần phải xử lý ngay. Đó là: “Perfect Forward Secrecy là cái vẹo gì?”. Để có thể hiểu đơn giản, bạn hình dung tình huống nhiều phiên làm việc chỉ sử dụng đúng 1 Encryption Key. Lúc này, nếu vì một lí do nào đó, cái key bị “compromised” (có thể tạm dịch là bị “xâm hại” nhưng tôi thấy từ này cũng không ổn lắm) thì toàn bộ nội dung mã hóa đã trao đổi sẽ đều có thể bị giải mã.

Để tránh tình huống này, bạn có thể dùng cách thay đổi Encryption Key trong mỗi phiên làm việc hay thậm chí thay đổi vài lần trong 1 phiên. Khi đó, nếu 1 Encryption Key bị “compromised” thì chỉ có dữ liệu sử dụng cái Encryption Key đó bị rò rỉ. Tất cả cá dữ liệu mã hóa trước đó với các Encryption Key khác đều vẫn an toàn. Và khi đó bạn đã có 1 thứ gọi là Perfect Forward Secrecy (PFS).

Xong câu hỏi đầu tiên, đến câu hỏi thứ 2: “Diffie-Hellman và Perfect Forward Secrecy liên quan gì nhau? ”. Như mọi khi, chuyện này sẽ dẫn đến chuyện khác. Cụ thể, câu hỏi trên sẽ dẫn đến cái khái niệm Static and Ephemeral Keys. Để tránh lan man, tôi sẽ chặn đứng cái mạch phát triển của câu chuyện bằng cách tóm gọn vấn đề như sau:

– Static Keys: Ý muốn nói đến các Encryption Key tạo ra một lần và xài nhiều lần (kiểu như dùng RSA tạo Certificate.  Bạn có thể xem thêm thông tin về Certificate như tôi giới thiệu trong Hướng dẫn tạo VPN Server miễn phí từ A đến Z – Phần 3: Cài đặt OpenVPN, EasyRSA và thiết lập Certificate Authority trên GCP VM Instance và Giải ngố WWW – Phần 3: HTTPS có gì ngon hơn HTTP;

– Ephemeral Keys: Ý muốn nói đến các Encryption Key tạo ra xài 1 lần xong rồi bỏ như các sản phẩm Durex chứ không chơi kiểu xài xong, rửa, cất, rồi xài lại được.

Như vậy, việc sử dụng Ephemeral Key cho mỗi session (hoặc nhiều key trong một session) sẽ giúp bạn có được Perfect Forward Secrecy.

Lưu ý:

– Không dùng Determinnistic Algorithm trong quá trình tạo Ephemeral Key để bảo đảm key được tạo ra có tính ngẫu nhiên và tránh được tình trạng re-use;

– Determinnistic Algorithm hiểu đơn giản là các thuật toán có thể xác định chính xác thông tin đầu ra dựa vào thông tin đầu vào.

Quay trở lại với ông Diffie-Hellman, đại ca này hỗ trợ cả Static và Ephemeral Keys. DH với Ephemeral Keys hỗ trợ PFS có 2 phương pháp:

– DHE Diffie-Hellman Ephemeral (hoặc EDH): tạo key cho mỗi session;

– ECDHE Ellptic Curve Diffie-Hellman Ephemeral dùng Ephemeral Key tạo theo ECC (ECDH dùng Static Key).

#3 Vấn đề của Diffie-Hellman và thực tế sử dụng 

Như tôi lưu ý ở cuối Mục 1.2, bạn sẽ thấy một điểm tối quan trọng đó là DH không có cơ chế nào hỗ trợ cho quá trình xác thực (authentication) các bên. Điều này có nghĩa DH sẽ có khả năng “ăn hành” rất cao với Man-in-the-Middle attack. Tôi dự kiến sẽ trình bày các thể loại “attack” riêng nhưng để dễ nắm bắt vấn đề tôi xin tóm lược như sau:

Theo minh họa trên nói trên, với dã tâm thọc gậy bánh xe cuộc trao đổi của Alice và Bob thì lúc này Eve sẽ bảo Alice: “Yo! Tui là Bob đây!” và trong một diễn biến khác với Bob, Eve sẽ nói: “Ku! Alice nè!”. Như vậy thực tế lúc này Alice sẽ nhận E của Eve thay vì B của Bob (Bob sẽ nhận E của Eve thay vì A của Alice). Hai con hàng Alice và Bob cứ tung tóe tâm sự dựa trên niềm tin mãnh liệt là cái “share secret” có từ DH sẽ bảo kê cho mọi nội dung trao đổi. Thật ra điều này đúng được 50% vì nó vẫn đảm bảo bảo mật thông tin của 2 phía, chỉ có điều là phía Alice/Bob với Eve.

Vì lí do đó, thực tế bạn sẽ thấy DH thường sẽ được dùng kết hợp một đối tác Asymmertric Encryption khác (như RSA hoặc ECC) để triển khai thêm phần authentication.

Góc trợ giúp: Bạn còn nhớ lúc cấu hình OpenVPN sau khi tạo Certificate để xác thực với RSA (Hướng dẫn tạo VPN Server miễn phí từ A đến Z – Phần 3: Cài đặt OpenVPN, EasyRSA và thiết lập Certificate Authority trên GCP VM Instance) bạn còn triển thêm cái DH (Hướng dẫn tạo VPN Server miễn phí từ A đến Z – Phần 4: Tạo Private Key và ký Certificate cho VPN Server, VPN Client và cấu hình OpenVPN Server)  không?

Như vậy bạn lại có thể thắc mắc “Sao không dùng mịa RSA luôn đi cho khỏe”

Xin thưa, để bảo đảm PFS như nói ở Mục 2,  RSA cũng sẽ cần sử dụng Ephemeral Key. Và việc tạo Ephemeral Key cho RSA và DH cũng tương đương với việc leo lên đỉnh núi bằng cách dùng 2 chân và cách ngồi cáp treo! Ngoài ra, cũng cần lưu lý với cùng Key Size, sức mạnh của DH cũng sẽ cao hơn so với RSA. Tôi sẽ bàn kỹ hơn về vấn đề này trong kỳ tới với các nội dung chi tiết về RSA.