Tìm hiểu độ an toàn trong mã hoá đầu cuối của hệ thống hội nghị truyền hình Zoom

31/05/2021 08:30
Theo dõi ICTVietnam trên

Do đại dịch COVID-19 toàn cầu, hệ thống hội nghị truyền hình Zoom đã được sử dụng rộng rãi. Vào tháng 10/2020, Zoom Video Communications đã triển khai mã hóa đầu cuối để bảo vệ các cuộc trò chuyện trong hội nghị.

Thế nhưng, gần đây vào ngày 15/4/2021, trong một công bố của Takanori Isobe và Ryoma Ito1 đã chỉ ra có đến 8 tấn công có thể xảy ra đối với tính năng mã hóa đầu của Zoom phiên bản 2.3.1. Tìm hiểu để hiểu đúng mức độ đảm bảo an toàn của Zoom sẽ giúp người dùng có phương án hợp lý khi sử dụng Zoom phục vụ công việc một cách an toàn, hiệu quả.

Tìm hiểu độ an toàn trong mã hoá đầu cuối của hệ thống hội nghị truyền hình Zoom - Ảnh 1.

Sau tiết lộ của Edward Snowden về các chương trình do thám, Mã hóa đầu cuối (E2EE) đã nhận được nhiều sự chú ý như là một công nghệ để bảo vệ quyền riêng tư của người dùng khỏi việc chặn bắt và giám sát hàng loạt các thông tin liên lạc được thực hiện bởi các tổ chức chính phủ như NSA (Cơ quan An ninh Quốc gia) của chính phủ Hoa Kỳ. Vì vậy, việc phân tích giao thức E2EE là rất quan trọng để tăng cường độ an toàn của E2EE vì các công nghệ E2EE chưa đủ trưởng thành và độ an toàn của chúng vẫn chưa được hiểu rõ mặc dù chúng được sử dụng rộng rãi trong thế giới thực.

COVID-19 và Zoom

Trong bối cảnh của đại dịch COVID-19 toàn cầu, khi việc triển khai các hội nghị trực tiếp bị ảnh hưởng nghiêm trọng thì các hệ thống hội nghị truyền hình đã trở nên thiết yếu không chỉ cho mục đích kinh doanh mà còn cho sử dụng riêng tư, học thuật và giáo dục. Hiện tại, Zoom là hệ thống hội nghị truyền hình được triển khai rộng rãi nhất trên thế giới. Số lượng người dùng hoạt động hàng ngày trên thế giới là khoảng 300 triệu người vào tháng 4 năm 2020. Zoom hiện là nền tảng quan trọng cho kinh doanh và giáo dục trực tuyến trên toàn thế giới.

Tìm hiểu độ an toàn trong mã hoá đầu cuối của hệ thống hội nghị truyền hình Zoom - Ảnh 2.

Zoom Video Communications lần đầu tiên công bố kế hoạch hỗ trợ E2EE vào tháng 5 năm 2020 để bảo vệ các cuộc để bảo vệ các cuộc trò chuyện khỏi những người không tham gia vào hội nghị, trong số đó có nhà cung cấp dịch vụ Zoom. Họ đã công bố các chi tiết kỹ thuật của các lược đồ mã hóa được xuất bản dưới dạng sách trắng [2]. Vào tháng 10 năm 2020, Zoom triển khai giai đoạn đầu thuộc dự án E2EE của họ và cung cấp E2EE trên toàn cầu cho người dùng Zoom trả phí cũng như miễn phí trong 30 ngày như một duyệt trước kỹ thuật.

Mô hình đối phương và các mục tiêu an toàn

Trong sách trắng, Zoom tuyên bố các mục tiêu an toàn về tính bảo mật, tính toàn vẹn và tính xác thực chống lại người bên trong, những người bên ngoài và những người tham gia hội nghị, trong đó người bên trong là nhà cung cấp dịch vụ, cụ thể là Zoom và những người bên ngoài là người dùng hợp pháp của Zoom nhưng không những người tham gia hội nghị mục tiêu. 

Mô hình đối phương

Mô hình đối phương trong hệ thống Hội nghị truyền hình bao gồm 04 đối tượng:

i- Người bên trong: Những người bên trong phát triển và duy trì cơ sở hạ tầng máy chủ của Zoom và các nhà cung cấp dịch vụ đám mây của nó. Người bên trong ác ý có thể chặn, đọc và sửa đổi bất kỳ luồng hội nghị nào được gửi qua mạng và có toàn quyền truy cập vào cơ sở hạ tầng máy chủ của Zoom.

ii- Người bên ngoài: Những người bên ngoài là những người dùng hợp pháp của hội nghị Zoom nhưng không phải là một phần của cơ sở hạ tầng tin cậy của Zoom và không có quyền truy cập vào thông tin kiểm soát truy cập hội nghị không công khai. Người bên ngoài ác ý có thể theo dõi, chặn và sửa đổi lưu lượng mạng và có thể cố gắng phá vỡ một trong các mục tiêu bảo mật trong các phiên E2EE khác bằng cách sửa đổi giao thức một cách ác ý.

iii- Những người tham gia hội nghị: Những người tham gia hội nghị có thể truy cập hội nghị, vì họ biết ID và mật khẩu của hội nghị hoặc thực hiện các ủy quyền đủ điều kiện khác. Người tham gia hội nghị ác ý cố gắng phá vỡ một trong các mục tiêu bảo mật bằng cách đi chệch khỏi giao thức.

iv- Người chủ trì hội nghị: Theo trong nội dung sách trắng, tồn tại một người chủ trì hội nghị trong số những người tham gia hội nghị và người đó có quyền cao hơn những người tham gia hội nghị khác. Người chủ trì hội nghị có trách nhiệm tạo khóa hội nghị dùng chung, cho phép những người tham gia hội nghị mới, xóa những người tham gia không mong muốn khỏi hội nghị và phân phối các khóa. Người chủ trì hội nghị ác ý cố gắng phá vỡ một trong những mục tiêu bảo mật bằng cách đi chệch khỏi giao thức.

Một người bên ngoài ác ý, một người tham gia hội nghị ác ý và một người chủ trì hội nghị ác ý có thể thông đồng với một người bên trong ác ý hoặc bản thân một người bên trong ác ý có thể là một người tham gia hội nghị ác ý hoặc một người chủ trì hội nghị ác ý.

Các mục tiêu an toàn

Công tác đảm bảo an toàn thông tin nhằm đáp ứng 3 mục tiêu: bảo mật, toàn vẹn và xác thực.

i- Tính bảo mật: Nếu chỉ những người tham gia hội nghị hợp pháp mới có thể xem các luồng hội nghị đã được giải mã, thì điều đó đảm bảo tính bảo mật rằng luồng hội nghĩ được giữ bí mật đối với tất cả trừ những người được phép xem nó.

ii- Tính toàn vẹn: Nếu luồng hội nghị được nhận và được xác minh thành công như xác thực thông điệp, thì nó đảm

bảo tính toàn vẹn dữ liệu rằng luồng hội nghị không bị thay đổi bởi các cách trái phép hoặc không được biết.

iii- Tính xác thực: Nếu luồng hội nghị được nhận và xác minh thành công như xác thực thực thể, thì nó đảm bảo tính xác thực rằng luồng hội nghị thực sự được gửi đi bởi một người tham gia hội nghị cụ thể.

Đặc tả kỹ thuật mã hóa đầu cuối cho hội nghị trực tuyến Zoom

Chi tiết về các thuật toán/giao thức trong mục này có ở trong sách trắng [2].

Các thành phần hệ thống

Kênh báo hiệu được sử dụng để phân phối các thông điệp đã được mã hóa giữa những người tham gia hội nghị. Những người tham gia hội nghị định tuyến các thông điệp điều khiển trên các đường hầm TLS trên TCP, thông qua các bộ định tuyến đa phương tiện, là một phần của cơ sở hạ tầng Zoom. TLS được kết thúc tại các máy chủ Zoom.

Mỗi hội nghị đều có bảng thông báo riêng mà những người tham gia hội nghị có thể truy cập được. Những người tham gia hội nghị có thể đăng các thông điệp có bảo mật lên bảng thông báo, bảng này được thực hiện qua kênh báo hiệu.

Máy chủ Zoom kiểm soát kênh báo hiệu và bảng thông báo, và do đó, nó có thể can thiệp các thông điệp có bảo mật được đăng trên bảng thông báo.

Các thuật toán mật mã

Tài liệu sách trắng có đến 55 trang, nó cho thấy rằng E2EE của Zoom dựa trên:

- AES-GCM [3] như thuật toán mã hóa có xác thực [3], - Thuật toán HKDF [4] như hàm dẫn xuất khóa,

- Diffie–Hellman trên đường cong Curve25519 [5] như lược đồ trao đổi khóa

- Chữ ký số EdDSA trên Ed25519 [6] như lược đồ chữ ký. Để khởi chạy một phiên E2EE cho hội nghị Zoom, người chủ trì hội nghị tạo khóa hội nghị và phân phối khóa đó một cách an toàn cho những người tham gia khác thông qua bảng thông báo bằng cách trao đổi khóa, hàm dẫn xuất khóa và lược đồ chữ ký. Sau đó, mỗi luồng hội nghị được mã hóa bởi AES-GCM bằng khóa hội nghị được chia sẻ.

Các thuật toán và giao thức đã được chỉ ra trong [3-6] là các thuật toán/giao thức an toàn về mặt mật mã, thế nhưng việc kết hợp chúng lại với nhau để tạo ra E2EE như trong sách trắng lại có một số lỗ hổng, chính vì thế mà các tác giả Takanori Isobe và Ryoma Ito đã phân tích ra có đến 8 tấn công có thể.

Khi người dùng Zoom nâng cấp ứng dụng Zoom của họ lên phiên bản đầu tiên hỗ trợ E2EE, họ sẽ tạo một cặp khóa chữ ký dài hạn. Sau đó, họ đăng ký khóa công khai của cặp khóa này lên máy chủ Zoom và lưu trữ khóa bí mật tương ứng trên thiết bị của họ. Họ tiếp tục sử dụng cặp khóa ký dài hạn này trừ khi họ cài đặt lại hệ điều hành hoặc cài đặt lại ứng dụng.

Giao thức tham gia/rời khỏi hội nghị và bảo mật khóa cục bộ

Giao thức thiết lập phiên E2EE cho các hội nghị Zoom bao gồm bốn giai đoạn: tạo khóa của người tham gia, khớp nối của người chủ trì, khớp nối tham gia của người chủ trì và khớp nối tham gia của người không chủ trì. Sau khi phiên E2EE được thiết lập, người chủ trì/những người tham gia mã hóa tất cả các luồng hội nghị với AES-GCM bằng cách sử dụng khóa hội nghị đã được chia sẻ trong giai đoạn khớp nối tham gia của người chủ trì/người không chủ trì như là đầu vào.

Để bảo vệ khóa ký lâu dài được lưu trữ trên thiết bị, mỗi người dùng Zoom sẽ mã hóa khóa ký dài hạn bằng lược đồ cam kết AEAD CtE1 [7].

Các lỗ hổng và tấn công có thể

Các lỗ hổng đã được chỉ ra

Lỗ hổng 1 - Không xác thực thực thể. Ngay cả khi một luồng hội nghị được nhận từ một người tham gia hội nghị cụ thể, tính xác thực của luồng hội nghị không được đảm bảo vì không có xác thực thực thể.

Lỗ hổng 2 - Truy cập tự do vào bảng thông báo. Những người bên trong và những người tham gia hội nghị có quyền truy cập tự do vào bảng thông báo. Đặc biệt, những người bên trong có thể tự do thu thập và can thiệp tất cả các giá trị, bao gồm cả chữ ký và các khóa công khai được tạo ra bởi những người tham gia riêng biệt, được đăng trên bảng thông báo.

Lỗ hổng 3 - Có cùng giá trị Binding như trong hội nghị trước đó. Nếu các ID hội nghị, đó là meetingID và meetingUUID, được tạo bởi những người bên trong và khóa công khai được sinh ra do người tham gia hội nghị được sử dụng lại, thì siêu dữ liệu Binding của người tham gia hội nghị có cùng giá trị. Vì cặp khóa ký của người tham gia hội nghị được sử dụng trong một thời gian dài, nên cùng một chữ ký luôn được tạo ra từ cùng một siêu dữ liệu Binding.

Lỗ hổng 4 - Khóa hội nghị do người chủ trì tạo. Chỉ người chủ trì hội nghị mới tham gia vào việc tạo khóa hội nghị dùng chung 256-bit.

Lỗ hổng 5 - Khóa ký dài hạn. Khóa ký thời hạn dài của người tham gia hội nghị được mã hóa bằng khóa bọc khóa được đồng bộ của máy chủ KWK. Bản mã được lưu trữ trên thiết

bị của người tham gia, nó có thể là máy tính được hai người dùng chia sẻ và KWK được lưu trữ trên máy chủ Zoom.

Lỗ hổng 6 - Sử dụng sai Nonce. Tất cả các luồng hội nghị đều được mã hóa bằng AES-GCM. Nếu đại lượng nonce được sử dụng không đúng cách trong hội nghị, các tấn công hiện có lên AES-GCM [8, 9, 10] sẽ được thực hiện và khóa xác thực sẽ bị lộ cho bên thứ ba.

Các tấn công có thể

Trong công bố của Takanori Isobe và Ryoma Ito, các tác giả đã tiến hành đánh giá kỹ lưỡng độ an toàn của mã hóa đầu cuối của Zoom (phiên bản 2.3.1) bằng cách phân tích các giao thức mật mã của chúng. Họ đã phát hiện ra một số cuộc tấn công mạnh hơn những cuộc tấn công mà Zoom mong đợi như đã được đề cập đến trong sách trắng. Cụ thể:

- Nếu người bên trong thông đồng với những người tham gia hội nghị, họ có thể mạo danh người dùng Zoom bất kỳ trong các hội nghị mục tiêu (target meeting), trong khi Zoom cho biết rằng người bên trong chỉ có thể mạo danh những người tham gia hội nghị hiện tại.

- Bên cạnh đó, ngay cả khi không dựa vào những người tham gia ác ý, những người bên trong có thể mạo danh người dùng Zoom bất kỳ trong các hội nghị mục tiêu mặc dù họ không thể giải mã các luồng hội nghị.

Mạo danh dựa trên không xác thực thực thể. Đầu tiên là tấn công mạo danh bởi những người tham gia hội nghị ác ý mà không thông đồng với những người bên trong. Tấn công này khai thác thực tế là không có xác thực thực thể của luồng hội nghị trong hội nghị nhóm. Cụ thể, dữ liệu luồng được gửi từ người tham gia hội nghị bất kỳ đều được mã hóa bởi AES-GCM bằng cùng một khóa hội nghị.

Mạo danh người dùng Zoom bất kỳ. Những người bên trong mà không thông đồng với những người tham gia có thể mạo danh bất kỳ người dùng Zoom hợp pháp nào, ngay cả người dùng không được mời, đối với hội nghị mục tiêu. Tấn công này khai thác thực tế là những người bên trong có quyền truy cập tự do vào các bảng thông báo và họ có thể phát hành ID và UUID của hội nghị, nó có chức năng như đại lượng không lặp lại của thông tin ràng buộc để xác định người dùng. Sử dụng các dữ kiện này, những người bên trong có thể sử dụng lại thông tin ràng buộc của người dùng Zoom, mà đã được đăng trên bảng thông báo trong các cuộc hội nghị trước đó, cho các hội nghị mục tiêu. Lưu ý rằng trong tấn công này, những người bên trong không thể giải mã luồng hội nghị vì khóa hội nghị của hội nghị mục tiêu là không được biết. 

Tuy nhiên, nó có thể có tác dụng phụ; ví dụ, trong trường hợp đàm phán, việc một người có ảnh hưởng tham dự có thể gây áp lực thầm lặng lên những người khác. Do đó, tấn công này có ý nghĩa trong thực tế.

Hơn nữa, nếu thông đồng với những người tham gia, những người bên trong có thể lấy được khóa hội nghị. Khi đó, họ mạo danh một cách hoàn toàn người dùng hợp pháp bất kỳ, tức là họ có thể chủ động tham dự hội nghị mục tiêu như người dùng mục tiêu

Mạo danh người dùng khác trên thiết bị dùng chung. Tấn công mạo danh trong trường hợp nhiều người dùng chia sẻ một thiết bị cho các hội nghị Zoom bằng cách thông đồng với những người bên trong. Trong tấn công này, một người dùng ác ý có thể nhận được khóa thiết bị của một người dùng khác mà sử dụng cùng một thiết bị cho các hội nghị Zoom. Tấn công này khai thác thực tế là khóa để mã hóa khóa thiết bị được lưu trữ trong máy chủ Zoom.

Tìm hiểu độ an toàn trong mã hoá đầu cuối của hệ thống hội nghị truyền hình Zoom - Ảnh 3.

Bảng trên tóm tắt kết quả của nhóm tác giả Takanori Isobe và Ryoma Ito: các tấn công mạo danh, can thiệp và từ chối dịch vụ. Mỗi kiểu tấn công được phân thành hai kiểu: tấn công chủ động và tấn công bị động. Trong một tấn công kiểu chủ động, đối phương có thể không chỉ tham gia hội nghị mục tiêu mà còn có thể gửi và nhận các luồng hội nghị một cách hợp thức. Trong một tấn công kiểu bị động, đối phương có thể thực hiện tấn công, nhưng không thể gửi và nhận các luồng hội nghị một cách hợp thức. Các mô hình đối phương và nạn nhân bao gồm người bên trong, người bên ngoài, người chủ trì hội nghị và người tham gia hội nghị, được ký hiệu lần lượt là BT (bên trong), BN (bên ngoài), CT (chủ trì) và TG (tham gia), “t.đ.v.” là từ viết tắt của “thông đồng với”.

Trong bản công bố, các tác giả cũng đã đề xuất các biện pháp phòng chống lại các tấn công đã chỉ ra.

Tiết lộ có trách nhiệm

Để chứng minh tính khả thi của các cuộc tấn công được đề xuất, thì cần phải thực hiện và thử nghiệm các cuộc tấn công đó. Tuy nhiên, nội dung bản công bố chỉ trình bày các đánh giá lý thuyết của E2EE cho Zoom vì mã nguồn của E2EE cho Zoom không có sẵn. Do đó, các tác giả đã thảo luận với Zoom để xác nhận tính khả thi của các cuộc tấn công được đề xuất.

Vào tháng 11/2020, Takanori Isobe và Ryoma Ito đã thông báo cho Zoom về những phát hiện của họ thông qua nền tảng tiết lộ lỗ hổng của Hacker One [11]. Zoom đã thừa nhận các kết quả đó và Zoom sẽ có kế hoạch giải quyết những vấn đề này trong phiên bản tương lai hoặc nêu rõ những vấn đề này là những hạn chế của phiên bản E2EE hiện tại của họ trong sách trắng.

Các phát hiện trình bày trong sách trắng không phải là mối đe dọa ngay lập tức đối với E2EE cho Zoom. Tuy nhiên, kết quả này thấy rằng có chỗ cần cải thiện trong E2EE cho Zoom như một lưCợc đồ mật mã. Những đánh giá bảo mật này có giá trị để hiểu rõ và tăng cường bảo mật của E2EE cho Zoom.

Tài liệu tham khảo:

1. Takanori Isobe và Ryoma Ito, Security Analysis of End-to-End Encryption for Zoom Meetings, https://eprint.iacr.org/2021/486

2. Josh Blum and Simon Booth and Oded Gal and Maxwell Krohn and Julia Len and Karan Lyons and Antonio Marcedone and Mike Maxim and Merry Ember Mou and Jack O'Connor and Miles Steele and Matthew Green and Lea Kissner and Alex Stamos. E2E Encryption for Zoom Meetings – Version 2.3, 2020. https: //github.com/zoom/zoom-e2e-whitepaper.

3. NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 2007. U.S.Department of Commerce/National Institute of Standards and Technology.

4. Hugo Krawczyk and Pasi Eronen. HMAC-based Extract-and-Expand Key Derivation Function (HKDF). Internet Engineering Task Force - IETF, Request for Comments, 5869, May 2010.

5. Daniel J. Bernstein. Curve25519: New Diffie-Hellman Speed Records. In Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, editors, Public Key Cryptography - PKC 2006, 9th International Conference on Theory and Practice of Public-Key Cryptography, New York, NY, USA, April 24-26, 2006, Proceedings, volume 3958 of Lecture Notes in Computer Science, pages 207–228. Springer, 2006.

6. Daniel J Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. High-speed high-security signatures. Journal of cryptographic engineer ing, 2(2):77–89, 2012.

7. Paul Grubbs, Jiahui Lu, and Thomas Ristenpart. Message Franking via Committing Authenticated Encryption. Cryptology ePrint Archive, Report 2017/664, 2017. http://eprint. iacr.org/2017/664.

8. Niels Ferguson. Authentication weaknesses in GCM. Comments on the Choice Between CWC or GCM to NIST, 2005.

9. David A. McGrew and John Viega. The security and performance of the Galois/Counter mode of operation (full version). Cryptology ePrint Archive, Report 2004/193, 2004. http:// eprint.iacr.org/2004/193.

10. Antoine Joux. Authentication Failures in NIST Version of GCM. Comments on The Draft GCM Specification to NIST, 2006.

(Bài đăng ấn phẩm in Tạp chí TT&TT số 5 tháng 5/2021)

Nổi bật Tạp chí Thông tin & Truyền thông
Đừng bỏ lỡ
Tìm hiểu độ an toàn trong mã hoá đầu cuối của hệ thống hội nghị truyền hình Zoom
POWERED BY ONECMS - A PRODUCT OF NEKO