Cách Server tìm kiếm siêu tốc trên khối dữ liệu mã hóa (Zero-Knowledge Search)

Làm sao để tìm kiếm trên một đống dữ liệu mà chính hệ thống cũng không biết nó là cái gì?

Hãy tưởng tượng anh em đang làm một app y tế hoặc app chat bảo mật (như Telegram, Signal). Tiêu chuẩn là End-to-End Encryption (E2EE). App mã hóa tin nhắn của khách hàng bằng AES-256-GCM rồi mới đẩy lên Server. Server chỉ cầm một đống rác (Ciphertext). Đùng một cái, sếp bảo: "Làm thêm tính năng ô tìm kiếm tin nhắn cho app nhé!".

Anh em sẽ làm gì? Tải toàn bộ 10GB tin nhắn mã hóa về điện thoại khách hàng, giải mã tại local rồi mới search? Điện thoại sẽ nổ tung vì cạn RAM và 3G. Còn bắt Server giải mã để search thì vứt luôn cái chữ "Bảo mật E2EE".

Hôm nay, chúng ta sẽ lặn xuống đáy của Mật mã học (Cryptography) và Kiến trúc hệ thống để giải quyết bài toán nghịch lý này.

Để giải quyết bài toán này, anh em phải nâng cấp tư duy qua từng Level, từ ngây ngô nhất đến đẳng cấp của những tập đoàn công nghệ tỷ đô.

Level 1: Deterministic Encryption (Mã hóa xác định) - Cú lừa bảo mật

Khi anh em xài thuật toán chuẩn như AES-CBC hoặc AES-GCM, nó sinh ra một cái gọi là IV (Initialization Vector) ngẫu nhiên. Điều này nghĩa là chữ "Viblo" mã hóa lần 1 ra chuỗi X!@#, mã hóa lần 2 lại ra chuỗi Y$%^. -> Vô phương tìm kiếm, vì Client gõ chữ "Viblo", app mã hóa ra chuỗi Z&*(, Server đem đi so sánh với DB thì chả có cái nào khớp cả.

Cách giải quyết của Junior: Dùng Deterministic Encryption (Mã hóa không có biến ngẫu nhiên). Nghĩa là chữ "Viblo" mã hóa 1 triệu lần vẫn chỉ ra duy nhất chuỗi X!@#. Lúc này, Client gõ "Viblo", mã hóa thành X!@#, đẩy lên Server. Server chỉ cần chạy SQL: SELECT * FROM messages WHERE encrypted_text = 'X!@#'; Bùm! Tìm ra ngay. Quá dễ đúng không?

SỰ THẬT TÀN KHỐC: Nếu anh em dùng cách này, hacker (hoặc DBA) nhìn vào Database sẽ đếm được tần suất. "Ủa sao cái mã X!@# này xuất hiện nhiều thế? Khả năng cao nó là chữ 'Xin chào' hoặc 'Ok'". Kĩ thuật này gọi là Frequency Analysis Attack, phá nát toàn bộ ý nghĩa của việc mã hóa.

Level 2: Blind Indexing (Chỉ mục mù) - "Chân ái" của kĩ sư thực dụng

Đây là cách mà 90% các hệ thống bảo mật hiện nay đang xài. Ý tưởng là: Tách riêng dữ liệu lưu trữ và dữ liệu dùng để search.

Bên Client, trước khi đẩy dữ liệu lên Server, nó sẽ làm 2 việc:

1. Lưu trữ: Mã hóa chữ "Viblo" bằng AES-256-GCM (có IV ngẫu nhiên) -> Ra một chuỗi rác an toàn tuyệt đối [Cipher_A].
2. Tạo Index: Dùng một thuật toán Hash một chiều (như HMAC-SHA256) kết hợp với một cái Secret Key (chỉ Client mới có) để băm chữ "Viblo" -> Ra chuỗi [Blind_Index_Viblo].

Gửi cả 2 cái này lên Server. Table trong Database sẽ trông như sau:

Khi Client muốn tìm chữ "Viblo": Nó lấy chữ "Viblo" băm với Secret Key -> ra hash_viblo. Nó gửi cái hash_viblo này lên Server. Server chạy SQL: SELECT Encrypted_Data FROM table WHERE Blind_Index = 'hash_viblo';

Đỉnh cao ở chỗ: Server tìm ra dữ liệu với tốc độ O(1) nhờ đánh Index thông thường trên cột Blind_Index, nhưng Server HOÀN TOÀN MÙ TỊT không biết hash_viblo nghĩa là gì vì nó không có Secret Key để dịch ngược.

Level 3: Search Partial (LIKE '%keyword%') với Trigram Hashing

Level 2 ngon, nhưng nó chỉ giải quyết được Exact Match (Gõ đúng 100% chữ "Viblo" mới ra). Nếu Client muốn gõ "Vib" mà vẫn tìm ra chữ "Viblo" thì sao? Blind Index bó tay, vì hash của "Vib" khác hoàn toàn hash của "Viblo".

Tuyệt kỹ N-grams (Trigram):

Client không hash cả chữ, mà nó băm nhỏ chữ "Viblo" ra thành các đoạn 3 kí tự (Trigram): Vib, ibl, blo. Nó băm (HMAC) từng mảnh này lại: [hash_Vib], [hash_ibl], [hash_blo]. Sau đó nó gửi CẢ 3 cái hash này lên Server, lưu vào một bảng Search_Index (quan hệ 1-N).

Khi user gõ "Vib", Client băm "Vib" ra [hash_Vib] và ném lên Server. Server tìm trong bảng Search_Index cái nào khớp [hash_Vib] thì trả về dữ liệu. Đây chính là cách Apple và Signal đang dùng để xử lý tìm kiếm danh bạ bị mã hóa!

Level 4: TEE (Trusted Execution Environment) - Sức mạnh của phần cứng

Nếu dữ liệu quá phức tạp, hoặc anh em muốn search Full-text như Elasticsearch, thì cách chia N-grams ở Level 3 sẽ làm bung bét Database (phình to gấp 100 lần).

Lúc này, các tập đoàn lớn (AWS, Intel) đẻ ra khái niệm TEE (Ví dụ: AWS Nitro Enclaves, Intel SGX). Hãy coi đây là một "Căn phòng bóng tối" nằm ngay bên trong con chip CPU của Server. Ngay cả ông chủ Server (Root Admin, Amazon) cũng KHÔNG THỂ nhìn vào căn phòng này.

1. Client gửi câu truy vấn đã mã hóa lên Server.
2. Server ném khối data mã hóa + câu truy vấn vào "Căn phòng bóng tối" (Enclave).
3. Tại đây, chỉ bên trong con chip CPU mới có chìa khóa để giải mã, bung dữ liệu ra thành Plaintext, cạy Elasticsearch tẹt ga để tìm kiếm.
4. Tìm xong, nó mã hóa kết quả lại, dọn dẹp sạch sẽ RAM trong căn phòng, rồi ném cục kết quả đã mã hóa ra ngoài cho Server trả về Client.

Anh em search dữ liệu siêu tốc, phức tạp bao nhiêu cũng được, mà Server vẫn chỉ cầm "vỏ bọc" mã hóa. Đây là công nghệ đang được xài trong các hệ thống xử lý dữ liệu Y tế chuẩn HIPAA hoặc Tài chính lõi.

Level 5: Trùm cuối - Fully Homomorphic Encryption (FHE)

Được mệnh danh là "Chén Thánh" (Holy Grail) của giới Mật mã học. FHE cho phép Server thực hiện phép toán (Cộng, Trừ, Nhân, Tìm kiếm) TRỰC TIẾP TRÊN CIPHERTEXT mà không cần giải mã, không cần TEE phần cứng.

Nghĩa là Encrypted(A) + Encrypted(B) = Encrypted(A + B).

Anh em ném một câu truy vấn mã hóa lên, Server lấy khối data mã hóa, chạy thuật toán FHE, nhả ra kết quả mã hóa. Gửi về Client giải mã là xong. Nhược điểm: Hiện tại (năm 2026), FHE vẫn còn quá chậm (chậm hơn hàng nghìn lần so với CPU tính toán bình thường) do độ phức tạp của Toán học. Nhưng đây chắc chắn là tương lai của Điện toán đám mây.

Tổng kết

Tóm lại, nếu anh em đang build một app cần Zero-Knowledge Search ở thời điểm hiện tại:

• Cần làm nhanh, dễ, tìm kiếm chính xác 100%: Dùng Blind Indexing (HMAC).
• Cần tìm gần đúng (LIKE): Dùng Blind Indexing + Trigram.
• Cần Full-text Search phức tạp: Cân nhắc kiến trúc phần cứng TEE (Intel SGX/AWS Nitro).

Nghề Kỹ sư phần mềm "cuốn" ở chỗ đó. Càng đào sâu, anh em càng thấy những thuật toán tưởng chừng bất khả thi lại được giải quyết bằng những lối tư duy cực kì "out trình".

Anh em có từng phải implement tính năng nào "khoai" cỡ này trong dự án thực tế chưa? Thả comment chém gió cùng mình nhé! Đừng quên 1 Upvote và Bookmark để lưu lại làm vốn liếng phỏng vấn các công ty tier-1!