TS. Đặng Minh Tuấn - tuanvietkey@gmail.com
Tóm tắt: Bài viết phân tích một số lỗ hổng bảo mật của phần mềm XYZ ở hai khía cạnh kỹ thuật lập trình an toàn và trên quan điểm của mật mã học trong khâu thiết kế kiến trúc hệ thống và sau đó bài viết cũng đưa ra một số khuyến nghị nhằm hướng tới một hệ thống phần mềm an toàn và hữu ích cho cộng đồng.
I. Mở đầu
Ngày sau khi công bố XYZ được 2 ngày, Dương Ngọc Thái (ThaiDN), chuyên gia bảo mật đang làm việc tại Google có công bố “Cảnh báo: lỗ hổng nghiêm trọng trong ứng dụng XYZ” [1]. Tuy không hoàn toàn nhất trí với 6 lỗ hổng mà ThaiDN công bố, nhưng tôi dù thấy còn một số luận điểm của ThaiDN chưa chính xác thì cũng đồng ý ở 3 điểm: XYZID cố định, ngắn và tạo ngẫu nhiên không an toàn có thể coi là những lỗ hổng nghiêm trọng. Tiếp sau đó, ThaiDN có liên tục 3-4 bài nữa cũng bàn về cùng chủ đề nhằm làm rõ thêm một số ý nhưng mọi việc dường như đã lắng xuống và số người cài đặt XYZ vẫn tăng hàng ngày và hôm nay đã lên đến hơn 163000 người. Nhận thấy rằng các lỗ hổng này vẫn mang tính trầm trọng nên tôi quyết định dành 2 ngày nghỉ lễ để phân tích các giải pháp của thế giới và của XYZ đồng thời sẽ viết và trình bày chi tiết các quan điểm cùng các chứng minh để thuyết phục team phát triển cần phải redesign lại toàn bộ kiến trúc cũng như nhanh chóng vá các lỗ hổng mà tôi phát hiện được trong phần II, phần III sẽ là các phân tích về các lỗ hổng liên quan đến an toàn phần mềm, phần IV phân tích kỹ hơn về định danh XYZID và phần V là kết luận và khuyến nghị.
II. Hãy đưa tôi điện thoại của bạn, tôi sẽ hack XYZ trong vòng 2 phút!
a/ Mô tả kịch bản
Tôi sẽ mô tả kịch bản này cho dòng máy Android (không dùng Iphone nên chưa nghiên cứu được lỗ hổng bảo mật trên nền tảng này.
1. Đầu tiên chúng ta hãy vào [Ch Play] download hai phần mềm QuickEdit và SQLiteView có biểu tượng như hình 1. (phần download này sẽ hết khoảng 1 phút).
 |
| Hình 1: Hai công cụ để hack XYZ. |
2. Mở ứng dụng Quickedit, vào [Cài đặt] và bỏ chọn [Loại bỏ lọc tập tin] để hiện các file ẩn.
3. Chọn thư mục XYZ và mở file [.id] theo hình 2.
 |
| Hình 2: Mơ file .id để nhập ID bất kỳ |
4. Điền ID bất kỳ gồm 6 ký tự, là các chữ A-Z, a-z,0-9. Sau khi edit xong lưu lại, tiếp theo gỡ XYZ đi và cài lại XYZ, chạy lại ứng dụng, XYZ sẽ nhận mã ID mới như hiình 3. Như vậy đã hack xong phần mã ID, tiếp theo thoát sang bước 5, hiển thị lịch sử những người gặp trong phạm li gần trước đó.
Hình 3: Đặt mã XYZ ID theo ý muốn: DMTuan
5. Ra màn hình home chạy ứng dụng SQLiteView chọn thư mục [XYZ/backup] như hình 4. Chọn file .app_backup và chọn trace_infor, lúc này chúng ta có thể xem được toàn bộ lịch sử gặp gỡ người dùng bao gồm mã XYZID của họ, địa chỉ MAC của thiết bị, thậm chí là tên của thiết bị do người dùng đặt, xem Hình 4. Như vậy trong vòng 2 phút chúng ta có thể xem được mọi thông tin lịch sử người dùng đã gặp (phần mềm XYZ không hiển thị các thông tin này trừ mã ID). Nguy hại hơn đó là trong 2 phút bất kỳ ai cũng có thể thay được mã ID bất kỳ.
 |
| Hình 4: Truy lịch sử gặp gỡ người dùng khác |
b/ Phân tích rủi ro, hệ lụy từ việc có được phần mềm XYZ đã bị hack
Với việc người dùng dễ dàng thay đổi mã XYZID sẽ dẫn đến một số hệ lụy nghiêm trọng sau:
- Số liệu về dịch bệnh sẽ không phản ánh chính xác tình hình dịch bệnh, do có thể bị người dùng can thiệp dẫn đến số liệu fake thông qua mã ID.
- Người dùng có thể đổi mã ID để trốn cách ly, họ có thể tạo ra mã ID mới chưa tiếp xúc với ai nên không có lịch sử dịch tễ lây nhiễm.
- Ngược lại người dùng khi biết được mã ID là F0 do backend cung cấp họ có thể tạo ra mã ID đã phơi nhiễm, hoặc tự tạo ra lịch sử để chứng minh họ là F1 để được cách ly (tạo ra lý do chính đáng để trốn việc hay hưởng một số lợi ích từ chăm sóc y tế như được xét nghiệm miễn phí...). Nguy hiểm hơn họ có thể lợi dụng khả năng tạo ra F0 để đối thủ của mình buộc phải cách ly, gây tốn kém và mất thời gian của đối thủ cũng như hệ thống Y tế Nhà nước. Hãy hình dung 1 fake F0 đi vào một tòa cao ốc, hay 1 trường học, họ có thể khiến hàng nghìn người bỗng dưng bị rơi vào diện cách ly bắt buộc.
- Khi mở được lịch sử gặp gỡ, người dùng dễ dàng biết được mã ID cũng những người đã gặp, và như vậy tính ẩn danh, và tính không truy vết bị vi phạm nghiêm trọng. Từ đó có thể dẫn đến việc khi phát hiện các trường hợp F1, F2 sẽ bị kỳ thị, tẩy chay dẫn đến bất ổn trong cộng đồng.
- Từ hình 4 cho thấy XYZ thu thập thông tin gồm cả địa chỉ MAC và định danh thiết bị cả với các thiết bị không cài phần mềm XYZ và đây là một sự vi phạm privacy nghiêm trọng, thu thập thông tin cá nhân bất chấp sự đồng ý của họ (khi cài XYZ thì có thể coi là chấp nhận điều khoản thu thập dữ liệu liên quan cá nhân).
III. XYZ cần nhanh chóng review lại toàn bộ kiến trúc theo các tiêu chí của An toàn phần mềm
Có một thực tế đáng buồn là ở Việt Nam, các anh em coder/dev hầu như không được học về An toàn phần mềm (Software Security Engineering) một cách bài bản mà đa phần chỉ nhanh nhanh chong chóng học một vài ngôn ngữ lập trình, một vài framework có sẵn và cắm đầu cắm cổ code, code, code và code, miễn sao nó chạy là được, hết lỗi logic là đã hài lòng. Rất ít khi từ khâu design, kiến trúc đã phải tính đến thiết kế về security của hệ thống ngay từ đầu rồi và xuyên suốt quá trình phát triển phần mềm đều phải tuân thủ các quy tắc, quy trình của an toàn phần mềm [9]. Trong giáo trình [9] có một thống kê viết rằng, nếu chi phí thiết kế tính là 1 đồng, thì chi phí khắc phục lỗi security ở khâu triển khai đã là 6.5 lần, và khắc phục lỗi security sau khi phát hành sẽ là gấp 60 lần! Xem Hình 5.
 |
| Hình 5: Chi phí khắc phục lỗi an toàn phần mềm |
Nói về An toàn phần mềm thì khá mất nhiều thời gian và vượt quá khuôn khổ bài viết này (Từ năm 2017 đến nay tôi được Học viện Kỹ thuật Mật mã mời giảng môn An toàn phần mềm cho lớp Cao học ngành An toàn thông tin và môn này cần tới 3 tín chỉ. Tôi cũng là giảng viên cơ hữu của Học viện Công nghệ Bưu chính Viễn thông, bộ môn An toàn thông tin, và được phân công dậy về Network Security, tiếc là trong XYZ phần Network rất thú vị ở Backend thì nhóm lại không Open). Vậy tóm lại yêu cầu của An toàn phần mềm là gì? Đó là Confidentiality (Bảo mật), Integrity (Tính toàn vẹn dữ liệu), Availability (Tính sẵn sàng), Accountability (Trách nhiệm giải trình), Non-repudiation (Tính chống chối bỏ) xem Hình 6.
 |
| Hình 6: Một số yêu cầu của An toàn phần mềm. |
Điều đáng nói ở đây là hầu như tất cả các yêu cầu về An toàn phần mềm thì XYZ đều chưa đáp ứng được.
Tính sẵn sàng/Tính rách nhiệm giải trình: đây là điểm khá mờ, bởi vì nhóm XYZ mới chỉ open mã nguồn của frontend và một phần code giả lập viết bằng C# cho backend (server), còn thiết kế hệ thống ở backend thì hoàn toàn không có thông tin. Phần Backend tuy chức năng không có nhiều, chủ yếu là nhận và phân tán thông tin về các F0. Tuy nhiên đây lại là thành phần rất quan trọng vì nó có thể phải phân phối dữ liệu dịch tễ đến 97 triệu người dùng Việt Nam, và phải có hệ thống tiếp nhận/ghi nhận tất cả các ca F0 vì thế phần backend phải có năng lực chịu tải rất cao, trong một thời điểm có khi phải phục vụ hàng triệu kết nối một lúc và đó là cả một vấn đề, không rõ khả năng scale, khả năng phân tải, cân bằng tải và khả năng High Avalaibility, cũng như hệ thống backup, hệ thống chống tấn công DDOS ra sao.
Ở phiên bản hiện tại về phía backend tôi cũng phát hiện ra một lỗ hổng cũng có thể khiến cho hệ thống XYZ bị tê liệt (DOS - Denial of Service ) đó là có thể dùng bất cứ trình duyệt nào cũng có thể gọi hàm API (Web Service) bằng lệnh (url - lick vào link sau là thực hiện lệnh):
Lời gọi này sẽ trả về trong trình duyệt tổng số người dùng đã đăng ký và cài XYZ (đây là đường dẫn thực không phải hệ thống giả lập), số tô đo là số người dùng thực tại
<Result xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/BSS">
<_x003C_Object_x003E_k__BackingField xmlns:d2p1="http://www.w3.org/2001/XMLSchema" i :type="d2p1:string">163278</_x003C_Object_x003E_k__BackingField>
<_x003C_Status_x003E_k__BackingField>0</_x003C_Status_x003E_k__BackingField>
</Result>Có thể thấy đây là lỗ hổng cũng khá nguy hiểm bởi vì nó cho phép ai cũng có thể query, truy vấn đến cơ sở dữ liệu, dù họ không cần dùng phần mềm của XYZ và cũng không cần phải là một user đã đăng ký của hệ thống (không có xác thực hay đăng nhập hệ thống để thực hiện query). Điều này sẽ cho phép hacker gửi một số lượng request/query lớn tới máy chủ backend và mỗi request máy chủ lại vẫn phải phục vụ, như vậy không chỉ phần API Gateway phải chịu tải mà lớp cơ sở dữ liệu ở dưới cũng phải chịu tải cao dẫn đến cạn kiệt tài nguyên tính toán, đáp ứng của hệ thống. Chỉ cần một vài tools đơn giản trong bộ Kali một sinh viên An toàn thông tin của PTIT cũng có thể làm tê liệt hệ thống backend của XYZ. Lỗ hổng này của https://apibz.xyz.com tôi không mô phỏng khai thác, bởi như thế là phá hoại và vi phạm pháp luật.
Ngoài ra phần implementation của XYZ frontend cũng tỏ ra chưa được chuyên nghiệp khi sử dụng hàm ngẫu nhiên (sẽ phân tích ở phần sau), hoặc khi đặt tên biến không thống nhất, XYZ frontend được viết bằng React Native có đoạn mã viết bằng javascript có đoạn viết bằng Java hoặc bằng swift nhưng biến để lưu mã XYZID lúc thì viết là UserID, lúc là UserCode, lúc khác lại là phonenumber.., có vẻ như các thành viên trong Team dev chưa có tiếng nói chung!.
Tính bảo mật: XYZ không có bất cứ thuật toán nào bảo đảm được tính bảo mật, mọi dữ liệu (nhiều thông tin mạng đâm tính riêng tư (privacy)) cũng đều được lưu trữ và xử lý ở dạng clear text không được mã hóa, đó cũng là một phần lý do tại sao tôi không cần những công cụ đặc biệt như IDEA Pro, hay các công cụ trong số hơn 400 tools của Kali mà vẫn có thể hack được XYZ ngay trên một chiếc điện thoại Android bất kỳ và chỉ trong vòng chưa đến 2 phút. Tính dư thừa thông tin trong cơ sở dữ liệu (Hình 4) cũng là điểm trừ trong tính bảo mật, nguyên tắc là càng ít thông tin gợi ý cho việc truy vấn và hack thì càng tốt. XYZ không có hoặc có nhưng rất yếu các cơ chế xác thực và ủy quyền (Authentication/Authorization) nên bất kỳ ai cũng có thể dễ dàng qua mặt được hệ thống, bằng chứng là tôi có thể tự tạo mã XYZID mới mà hệ thống vẫn chấp nhận như thường và cung cấp các quyền đầy đủ cho tôi như ở kịch bản hack ở phần trên. Hệ thống cũng tăng khả năng truy vết và làm mất tính nặc danh (mục b phần II).
Tính toàn vẹn dữ liệu: XYZ cũng không có bất cứ cơ chế nào để bảo đảm tính toàn vẹn của dữ liệu, điều này khiến cho dữ liệu dù có không toàn vẹn (có lỗi) hay có sự can thiệp của Hacker hay gian lận tiêu cực của chính đội ngũ vận hành hệ thống cũng không có khả năng kiểm soát và phát hiện (Họ có thể xóa vài trường thông tin hay xóa luôn cả log liên quan, hệ thống cũng không thể phát hiện được.
Tính chống chối bỏ: là tính người dùng hy người admin không thể phủ nhận những hành vi của họ trong hệ thống. XYZ cũng không có biện pháp nào để bảo đảm và chứng minh được khả năng chống chối bỏ (phương pháp ghi log cơ bản không đáp ứng được vì log không có tính toàn vẹn và có thể sửa xóa một cách dễ dàng (nhất là khi có toàn bộ mã nguồn XYZ trong tay).
Cả 3 tính chất cuối cùng của An toàn phần mềm đòi hỏi phải áp dụng các kỹ thuật của ngành mật mã học (Cryprography): thuật toán mã hóa đối xứng và bất đối xứng, hàm băm, chữ ký số, sinh số ngẫu nhiên, trao đổi khóa và trong những ứng dụng đòi hỏi bảo độ tính riêng tư cao (privacy) và xác thực thì không thể thiếu một hay nhiều giao thức bảo mật: Security Protocol.
Qua những lỗ hổng đã phân tích ở trên về mặt xây dựng phần mềm, dù được phát triển bởi tập đoàn công nghệ lớn và nổi tiếng và có sự phối kết hợp của nhiều chuyên gia trong và ngoài nước cũng như một số nhóm và tập đoàn khác nhưng vẫn có thể thấy rõ là thiết kế hệ thống của XYZ đang thiếu bàn tay của các chuyên gia về An toàn phần mềm và chuyên gia mật mã.
IV. Mã XYZID cần một giao thức an toàn (Security Protocol)
Phần này tôi sẽ phân tích sâu hơn về giải pháp và kiến trúc của XYZ, và sẽ trao đổi thảo luận với một số ý kiến xung quanh về mã XYZID.
a/ Về ý kiến của ThaiDN trong bài công bố đầu tiên [1]:
- Điểm 2/, ThaiDN đã tự đính chính.
- Điểm 5/, lộ mã F0 là chức năng chứ không phải lỗi, hệ thống theo thiết kế là sẽ quảng bá tối đa mã ID của F0, vì mã ID là nặc danh nên không lộ danh tính, đó là theo thiết kế.
- Điểm 6/, cấp quyền cho app, đó là yêu cầu không phải lỗ hổng, rất nhiều app cũng yêu cầu cấp quyền tương tự, đó là hệ điều hành cho phép, và người dùng tự cân nhắc dùng hay không.
- Điểm 3/, chưa chính xác, kích thước không gian mã ngẫu nhiên của XYZID phải là 62^6=56,800,235,584 chứ không phải là 36^6 (ThaiDN quên mất hàng chữ thường a-z). Cũng ở điểm này tôi thực sự không rõ ThaiDN tính số người có thể trùng ID sao ra thành 2^16. Công thức để tính số người có thể trùng ID, theo nghịch lý ngày sinh nhật là [10]: $n\approx {\sqrt {2m\times p(n)}} = \sqrt {2\times 36^6 \times p(1)} = 65,981$, còn với số thực tế theo thiết kế hiện nay của XYZ sẽ là: $n\approx {\sqrt {2m\times p(n)}} = \sqrt {2\times 62^6 \times p(1)} = 337,046$. Với 97 triệu người ở Việt Nam thì chia ra sẽ có khoảng 288 cặp là 576 người bị trùng ID. Theo tính toán của tôi nếu dùng mã ID là 9 ký tự sẽ an toàn hơn khi với 164 triệu người mới có 2 người trùng ID.
- Hai điểm 1/ và 4/ tôi về cơ bản cũng đồng quan điểm.
b/Về ý kiến của nhóm XYZ thông qua BQT WhiteHat.vn, và trực tiếp trên Github [2]
- Điểm 1/ Nhóm XYZ khẳng định dịa chỉ MAC luôn cố định vì luôn có Bluetooth Classic, điều này là chưa chính xác, có thể nhóm đã chưa hiểu rõ đặc tả Bluetooth Core Specification version 4.0 - Bluetooth Smart (Từ 6-2010), với phiên bản này Bluetooth 4.0 cung cấp cả 3 giao thức Classic Bluetooth, Bluetooth high speed và Bluetooth Low Energy (BLE) protocols. Với Bluetooth Smart địa chỉ MAC đã có thể thay đổi một cách ngẫu nhiên trong vòng 16-45 phút tùy thiết bị [11], Bluetooth 4.0 chỉ dùng Bluetooth Classic khi kết nối với thiết bị Bluetooth cũ hoặc những thiết bị đòi hoi thời gian kết nối dài như tai nghe, bút vẽ, bàn phím... Như vậy từ 2010 địa chỉ MAC đã thay đổi một cách ngẫu nhiên (trừ các thiết bị cũ), để tránh việc đổi mã ngẫu nhiên của thiết bị với mã ngẫu nhiên trên app bị lệch pha dẫn tới vẫn cón thể track được thiết bị thì cần phải có thông báo notification từ thiết bị khi chuẩn bị có thay đổi địa chỉ MAC, hiện tại chỉ riêng IOS là không có notification khi đổi MAC (Android thì có) và điều này sẽ làm khó cho việc đồng bộ đổi mã ngẫu nhiên cùng lúc để tránh tracking. Như vậy với các thiết bị mới ngày nay thì địa chỉ MAC đã có thể thay đổi ngẫu nhiên (từ 2010) để tránh Tracking. Vì sự hiểu chưa đúng này mà nhóm đã quyết định dùng XYZID cố định thì rõ ràng đã làm nguy cơ bị truy vết tăng lên rất nhiều nhát là khi có cả lịch sử gặp gỡ được bộc lộ như ở Hình 4. Với trợ giúp của dữ liệu này người dùng có thể xác định rõ danh tính của một người khác cả mã ID và cả tên thiết bị khi họ đến gần người cần quan tâm. Như vậy mục tiêu ẩn danh của thiết kế XYZ đã có thể dễ dàng bị loại bỏ bên cạnh việc dẽ dàng truy vết tracking do dùng ID cố định.
- Điểm 3/ "Nhóm phát triển cho biết, trong quá trình thiết kế, không giải quyết các tình huống trùng ID (bất kể xác suất nào)", có thể nói ngay rằng khẳng định này rất rất khó được chấp nhận. Định danh ID -Identifcation được thiết kế đê định danh, để phân biệt giữa thực thể này với thực thể khác, giữa người này và với người khác, và vì sao trong Cơ sở dữ liệu chúng ta có primary key, nhất quyết không được trùng nhau. Thiết kệ một hệ ID mà xác suất trùng cao thì rõ là một thiết kế không tốt. Có thể lấy ví dụ về trường hợp trùng ID. Giải sử có 3 người trùng nhau ID thì chỉ cần một người bị cho là F0 thì lập tức 2 người kia cũng bị theo và như vậy 1 người ở Hà Nội bị F0, thì tất cả những người tiếp xúc gần với 2 người kia đều là F1 (dù họ ở Đà Nẵng hay TP.HCM) và những người tiếp xúc với 2 người này đều phải bị cách ly bắt buộc. Cũng trong điểm 3, ý tưởng dùng cơ quan y tế để xác định người F0 và đưa lên kênh chung không phải là đặc sắc và mới (chưa có ai làm được) vì đó là quy trình phổ thông mà dự án DP-3T cũng thực hiện tương tự.
- Điểm 4/ "Nhóm phát triển cho biết họ dùng hàm sinh ngẫu nhiên theo millisecond. Cần đoán chính xác đến millisecond của 1 người thì chúng ta tự biết là có thể làm điều đó hay không" có thể tham khảo mã nguồn phần sinh mã ngẫu nhiên ở [3].
Random rand = new Random(System.currentTimeMillis());
Nhìn vào việc sinh mầm ngẫu nhiên dùng currentTimeMillis() là đủ thấy tác giả không phải thuộc chuyên ngành mật mã. Tôi luôn nói với các sinh viên rằng có 2 loại số vô cùng quan trọng trong ngành mật mã mà nhân loại mãi vẫn chưa hiểu hết về chúng và khi đã hiểu cặn kẽ chúng rồi thì có lẽ chẳng ai sẽ dùng chúng trong mật mã nữa. Đó chính là số nguyên tố và số ngẫu nhiên. Dựa trên số nguyên tố mà chúng ta có trường Galois và chứng minh được tính nghịch đảo và có nghiệm duy nhất của các thuật toán mã, còn số ngẫu nhiên chính là thường dùng để tạo ra khóa (keys) cho các thuật toán này, số ngẫu nhiên cũng được dùng để tạo ra địa chỉ MAC, định dah ID...
Lý thuyết và thực tế đã chứng minh chỉ có nguồn ngẫu nhiên lấy từ các qubit từ máy tính lượng tử (quantum computer) mới thực sự là ngẫu nhiên (True Random), còn lại đa phàn là các nguồn khó đoán định như: nguồn nhiễu ở cổng Audio của máy tính, vị trí đầu từ trong ổ cứng, vị trí con chuột trên màn hình... Tuy nhiên các nguồn này sẽ khá khó khăn để thực hiện vì vậy trong các thuật toán người ta thường dùng các hàm giả ngẫu nhiên (Pseudo Random Function) là các hàm mà đầu vào giống nhau sẽ cho ra kết quả ngẫu nhiên giống nhau, về để tạo ra sự ngẫu nhiên khó đoán định thì cần phải lựa chọn số mầm ngẫu nhiên (seed) càng có nhiều Entropy càng tốt (càng nhiều sự nhiễu loạn).
Trong thực tế rất ít khi người ta dùng thời gian hiện tại currentTimeMillis() làm mầm ngẫu nhiên vì trong 1 giây có đến 1000 thời điểm có thể trùng nhau, như vậy chỉ cần 1001 người đăng ký trong 1 giây thì sẽ có 2 người trùng. mầm ngẫu nhiên nếu có dùng thời gian để tạo mầm thì ít ra người ta sẽ Time Stamp Counter (TSC) tính từ thời điểm reset (đây là cách mà OpenSSL thường sinh số ngẫu nhiên), vì xác suất thời điểm reset máy trùng nhau sẽ ít hơn rất rất nhiều, so với số mili giây ở thời điểm hiện tại. Trong các nền tảng Blockchain thường để tạo ra private key người ta dùng kết hợp cả các hàm ngẫu nhiên do ngôn ngữ cung cấp [random()], hệ điều hành cung cấp và cả hàm giả ngẫu nhiên được cài sẵn trong CPU (nếu là của Intel thì dùng hàm:
__asm__ volatile (".byte 0x0f, 0xc7, 0xf0;" // rdrand %eax
".byte 0x0f, 0xc7, 0xf2;" // rdrand %edx
"setc %2" :
"=a"(r1), "=d"(r2), "=q"(ok) :: "cc"); Viết dài vậy để nói một điều: sinh số ngẫu nhiên luôn luôn là một vấn đề rất nhạy cảm, quay lại với mã nguồn trên Android của XYZ , nếu không dùng currentTimeMillis() thì dùng hàm gì? Đó là hàm sau:
SecureRandom random = new SecureRandom()Bởi vì hàm này được thiết kế để tuân thủ tiêu chuẩn FIPS 140-2, Security Requirements for Cryptographic Modules và tương hợp với RFC 1750: Randomness Recommendations for Security.
c/ Ý kiến cá nhân:
Trong tất cả các whitepaper của các dự án tương tự, vấn đề quan trọng nhất và được đề cập đầu tiên cũng như xuyên suốt quá trình thiết kế là bảo đảm tính riêng tư (privacy) và bảo đảm tính minh bạch của hệ thống, thông qua việc mở mã nguồn của toàn bộ hệ thống, ở mức cao hơn nữa là mở cả về dữ liệu (ai cũng có thể tiếp cận được). Với việc mở mã nguồn, tất cả các thuộc toán đều được công bố công khai, không có các bí mật hay password được gắn hard code trong mã nguồn, vì thế để có được tính minh bạch trong khi vẫn bảo đảm tính riêng tư bí mật cá nhãn, thì chỉ có thể dùng Security Protocol với các thuật toán an toàn (hacker không thể có đủ tài nguyên để giải trong hàng ngàn năm), tính bí mật cũng được bảo đảm trong vận hành thông có qua các khóa hay các mầm bằng các số ngẫu nhiên mạnh.
Các giải pháp của Châu Âu như DP3T, TCN đều được thiết kế với Security Protocol chặt chẽ thông qua số ngẫu nhiên cùng với sử dụng hàm băm an toàn và các lược đồ chữ ký số hiện đại dựa trên dường cong Elliptic như ECDSA (Elliptic Curve Digital Signature Algorithm) hay mới hơn là EdDSA (Edwards-Curve Digital Signature Algorithm), tuy nhiên những giải pháp này cũng tương tư như XYZ vẫn cần có sự vận hành của con người (cơ quan ý tế và đội ngũ admin), và hệ thống vẫn cần phải có sự tin tưởng ở quy trình và đạo đức của các thành viên chức năng (chưa có giải pháp nào có khả năng bảo đảm tính toàn vẹn dữ liệu và bảo đảm độ tin cậy của dữ liệu mà không phụ thuộc con người. Các hệ thống phòng chống dịch COVID=19 đòi hỏi có sự tham gia đông đảo đội ngũ y tế và quản trị ở rải rác trên nhiều khu vực địa lý khác nhau do đó khi đội ngữ này lớn lên theo nhu cầu thì khả năng nhầm lẫn, tiêu cực ngay trong chính hệ thống cán bộ là một nguy cơ không nhỏ. Trong những hệ thống như vậy chỉ có sự tham gia của công nghệ Blockchain bằng việc bảo vệ tính toàn vẹn và tin cậy của dữ liệu thông qua các thuật toán mật mã mạnh. Do đó các hệ thống phòng chống COVID-19 vẫn còn nhiều vấn đề phải nghiên cứu và giải quyết.
V. Kết luận và khuyến nghị
Từ các phân tích ở trên về các lỗ hổng bảo mật khá nghiệm trọng trong thiết kế An toàn phần mềm và những lỗ hổng hệ lụy từ việc thiếu một Security Protocol cho việc bảo vệ tính riêng tư của người dùng đặc biệt thông qua hệ thống định danh. Dự án XYZ dù được phát triển bởi các tập đoàn lớn và có các cơ quan ban ngành liên quan hỗ trợ và phản biện nhưng có thể nhận thấy trong dự án vẫn thiếu vắng một công trình sư hoặc nhóm chuyên gia dày dặn kinh nghiệm về phát triển hệ thống về an toàn phần mềm và chuyên gia về mật mã học.
Việc khuyến nghị cần làm ngay là thông báo rộng rãi để mọi người hạn chế cài đặt phiên bản có lỗ hổng và nhanh chóng vá các lỗi kể trên đồng thời có thể phải thiết kế lại cơ chế nhận thông báo F0 và từ bỏ hệ thống định danh cố định và thay bằng định danh động (ngẫu nhiên) như các dự án khác đang được dùng phổ biến ở Châu Âu: DP3T [12], hay Temporary Contact Number (TCN) càng sớm càng tốt (có thể kế thừa một phàn hoặc toàn bộ).
Cuối cùng tôi bày tỏ lòng cảm ơn chân thành tới các cơ quan ban ngành chức năng cùng team phát triển đã hết lòng vì cộng đồng nhằm phòng tránh tối đa khả năng nhiễm dịch COVID-19, bài phân tích này được viết ra với mong muốn để Việt Nam sớm có một hệ thống công nghệ thông tin chống dịch hữu hiệu và an toàn cho tất cả người dân Việt Nam.
VI. Tài liệu tham khảo
[1] D. N. Thái, “Cảnh báo: lỗ hổng nghiêm trọng trong ứng dụng XYZ”, https://vnhacker.blogspot.com, 24-4-2020. [Online]. Available: link.
[2] BQT WhiteHat.vn, "Phân tích các vấn đề liên quan đến XYZ", https://whitehat.vn, 25-4-2020, [Online]. Available: link.
[3] ntcuong, "XYZGlobal/react-native-bluetooth-scan", github, 27-4-2020. [Online]. Available: link.
[4] P. D. Hiệu, "XYZ: phần mềm cảnh báo tiếp xúc với Covid-19", facebook, 30-4-2020, [Online]. Available: link.
[5] Mai Hà, "Thực hư thông tin XYZ 'ảnh hưởng an toàn và riêng tư của người dùng", https://thanhnien.vn/, 26-4-2020, [Online]. Available: link.
[6] Minh Nhật, "Phần mềm chống Covid-19 của VN công khai mã nguồn, khẳng định an toàn", https://zingnews.vn, 27-4-2020, [Online]. Available: link.
[7] Bkav, "Ra mắt ứng dụng XYZ phòng chống COVID-19", https://www.bkav.com.vn, 22-4-2020, [Online]. Available: link.
[8] Cổng thông tin điện tử Bộ Y tế, "Thủ tướng dự khai trương 2 sản phẩm công nghệ giúp phòng chống COVID-19", 18-4-2020. https://moh.gov.vn, [Online]. Available: link.
[9] M. G. Rickenbach and P. H. Gobster, Secure Coding Principles and Practices, no. September 2003.
[10] Wikipedia, Birthday problem, [Online]. Available: link.
[11] J. K. Becker, David Li, and D. Starobinski, "Tracking Anonymized Bluetooth Devices", Proceedings on Privacy Enhancing Technologies ; 2019 (3):50–65.
[12] C. Troncoso, M. Payer, Decentralized Privacy-Preserving Proximity Tracing , 12-4-2020. [Online]. Available: link.