Khi Google công bố tính năng mã hóa đầu cuối (E2EE) sắp ra mắt cho người dùng Gmail doanh nghiệp, nhiều người đã tỏ ra nghi ngờ, cho rằng đây không phải là E2EE thực sự theo định nghĩa trong giới bảo mật và quyền riêng tư. Đồng thời, không ít người tò mò về cơ chế hoạt động chính xác của nó. Chúng ta hãy cùng tìm hiểu những gì dịch vụ mới này làm được và không làm được, cũng như nền tảng bảo mật cơ bản của nó. Trong bối cảnh này, khi Google sử dụng thuật ngữ E2EE, họ muốn nói rằng email được mã hóa ngay bên trong trình duyệt của người gửi, dù là Chrome, Firefox hay bất kỳ trình duyệt nào khác. Trong suốt quá trình di chuyển đến đích, thư vẫn được mã hóa và không thể giải mã cho đến khi nó đến đích cuối cùng, nơi nó được giải mã trong trình duyệt của người nhận. Điểm hấp dẫn chính của dịch vụ mới này là nó cho phép các cơ quan chính phủ và doanh nghiệp hợp tác tuân thủ hàng loạt quy định về bảo mật và quyền riêng tư, đồng thời loại bỏ những rắc rối lớn thường gặp khi triển khai các hệ thống email tuân thủ quy định tương tự. Cho đến nay, phương pháp phổ biến nhất là S/MIME, một tiêu chuẩn phức tạp và khó khăn đến mức chỉ những tổ chức dũng cảm và có nguồn lực tốt nhất mới dám triển khai. S/MIME yêu cầu mỗi người gửi và người nhận phải có chứng chỉ X.509 do một cơ quan cấp chứng chỉ (CA) cấp. Việc lấy, phân phối và quản lý các chứng chỉ này một cách an toàn tốn nhiều thời gian, tiền bạc và sự phối hợp. Điều này có nghĩa là nếu Bob và Alice chưa từng làm việc cùng nhau trước đây và phát sinh nhu cầu cấp bách hoặc bất ngờ để Bob gửi cho Alice một tin nhắn được mã hóa ngay lập tức, họ sẽ không thể làm được cho đến khi quản trị viên đăng ký chứng chỉ và cài đặt nó trên máy của Alice – điều này làm mất đi tính linh hoạt và nhanh nhạy. Google cho biết E2EE Gmail đã loại bỏ sự phức tạp này. Thay vào đó, Bob soạn một email cho Alice, nhấp vào nút bật tính năng và nhấn gửi. Trình duyệt của Bob mã hóa tin nhắn và gửi nó cho Alice. Tin nhắn chỉ được giải mã sau khi nó đến trình duyệt của Alice và cô ấy xác thực danh tính của mình. Để thực hiện điều này, tổ chức của Bob triển khai một máy chủ khóa gọn nhẹ theo mô tả của Google, được gọi là KACL (Key Access Control List - Danh sách kiểm soát truy cập khóa). Máy chủ này, có thể được lưu trữ tại chỗ hoặc trên hầu hết các dịch vụ đám mây, là nơi các khóa được tạo và lưu trữ. Khi Bob gửi một tin nhắn được mã hóa, trình duyệt của anh ấy kết nối với máy chủ khóa và nhận một khóa mã hóa đối xứng tạm thời (ephemeral symmetric encryption key). Trình duyệt của Bob mã hóa tin nhắn và gửi nó cho Alice, kèm theo một khóa tham chiếu (reference key). Trình duyệt của Alice sử dụng khóa tham chiếu để tải khóa đối xứng từ KACL và giải mã tin nhắn. Sau đó, khóa này sẽ bị xóa. Để ngăn chặn Mallory hoặc một kẻ tấn công trung gian (adversary-in-the-middle) khác lấy được khóa, Alice trước tiên phải xác thực danh tính của mình thông qua Okta, Ping hoặc bất kỳ nhà cung cấp danh tính (IDP) nào khác mà tổ chức của Bob sử dụng. Nếu đây là lần đầu tiên Alice nhận được tin nhắn từ tổ chức của Bob, trước tiên cô ấy sẽ phải chứng minh với IDP rằng cô ấy có quyền kiểm soát địa chỉ email của mình. Nếu Alice dự định nhận email được mã hóa từ tổ chức của Bob trong tương lai, cô ấy sẽ thiết lập một tài khoản có thể sử dụng cho các lần sau. Tổ chức của Bob có thể thêm một lớp bảo vệ bổ sung bằng cách yêu cầu Alice phải có sẵn tài khoản trên IDP và xác thực thông qua đó. Julien Duplant, giám đốc sản phẩm Google Workspace, chia sẻ với Ars Technica: “Ý tưởng là, dù thế nào đi nữa, Gmail không bao giờ và không có cách nào có được khóa thực sự. Chúng tôi cũng không bao giờ có nội dung đã giải mã. Nó chỉ xảy ra trên thiết bị của người dùng đó.” Tuy nhiên, liệu điều này có cấu thành E2EE thực sự hay không, thì có lẽ là không, ít nhất là theo các định nghĩa chặt chẽ hơn thường được sử dụng. Đối với những người theo chủ nghĩa thuần túy, E2EE có nghĩa là chỉ người gửi và người nhận mới có phương tiện cần thiết để mã hóa và giải mã tin nhắn. Điều này không đúng trong trường hợp này, vì những người trong tổ chức của Bob đã triển khai và quản lý KACL mới là người thực sự nắm giữ khóa. Nói cách khác, quá trình mã hóa và giải mã thực tế xảy ra trên thiết bị của người dùng cuối, không phải trên máy chủ của tổ chức hay bất kỳ nơi nào khác ở giữa. Đó là phần mà Google gọi là E2EE. Tuy nhiên, các khóa lại do tổ chức của Bob quản lý. Quản trị viên có toàn quyền truy cập có thể xem trộm các thông tin liên lạc bất cứ lúc nào. Cơ chế làm cho tất cả điều này trở nên khả thi là cái mà Google gọi là CSE (Client-Side Encryption - Mã hóa phía máy khách). Nó cung cấp một giao diện lập trình đơn giản giúp hợp lý hóa quy trình. Cho đến nay, CSE chỉ hoạt động với S/MIME. Điểm mới ở đây là một cơ chế để chia sẻ khóa đối xứng một cách an toàn giữa tổ chức của Bob và Alice hoặc bất kỳ ai khác mà Bob muốn gửi email. Tính năng mới này có giá trị tiềm năng đối với các tổ chức phải tuân thủ các quy định khắt khe yêu cầu mã hóa đầu cuối. Nó chắc chắn không phù hợp với người tiêu dùng hoặc bất kỳ ai muốn kiểm soát duy nhất các tin nhắn họ gửi. Những người ủng hộ quyền riêng tư cần lưu ý điều này khi đánh giá giải pháp, cân nhắc sự đánh đổi giữa tiện ích quản lý và quyền kiểm soát tuyệt đối đối với khóa mã hóa.
