Hàm băm, chữ ký, bản dựng tái lập và kiểm toán trả lời những câu hỏi khác nhau.
Mã nguồn mở cho phép kiểm tra mã; nhưng tự nó không chứng minh ứng dụng đã cài đặt chính là mã đó hay không có lỗ hổng. Để đánh giá một ứng dụng nhắn tin, tốt hơn hết nên tách biệt các loại bằng chứng: mã nguồn, quy trình xây dựng, chữ ký tệp, kiểm thử giao thức và báo cáo kiểm toán.
Mỗi bằng chứng cho thấy chính xác điều gì?
| Bằng chứng | Lợi ích chính | Điều không tự chứng minh được |
|---|---|---|
| Mã nguồn có thể đọc | Cho phép kiểm tra thiết kế và triển khai | Khớp với tệp cài đặt hay không có mọi lỗi |
| Bản dựng tái lập | Cho phép so sánh đầu ra từ nguồn và môi trường xác định | Bản thân mã là an toàn |
| Chữ ký APK | Kiểm tra chữ ký và liên kết tệp với khóa của người ký đáng tin cậy | Hành vi của ứng dụng là vô hại |
| Hàm băm SHA-256 | Phát hiện khác biệt về byte so với giá trị băm đáng tin cậy | Tính xác thực khi kẻ tấn công thay cả tệp lẫn giá trị băm |
| Vectơ kiểm thử | Kiểm tra hành vi cụ thể với đầu vào và đầu ra xác định | Bao phủ mọi trạng thái và đường thực thi |
| Kiểm toán độc lập | Các phát hiện khi kiểm tra một phạm vi và phiên bản cụ thể | Bảo đảm vĩnh viễn cho mọi phiên bản tương lai |
Bản dựng tái lập không đồng nghĩa với tải xuống tệp có cùng hàm băm
Theo định nghĩa của Reproducible Builds, khả năng tái lập liên quan đến việc tạo ra đầu ra giống hệt nhau từ mã nguồn, môi trường và hướng dẫn xác định. Nếu chỉ so sánh tệp tải xuống với giá trị băm do nhà phát triển công bố, bạn đã thực hiện kiểm tra tính toàn vẹn; bạn vẫn chưa tự xây dựng tệp từ mã nguồn.
Để đánh giá tuyên bố về khả năng tái lập, hãy yêu cầu phiên bản mã, các phần phụ thuộc, hướng dẫn xây dựng và báo cáo của người khác đã lặp lại kết quả. Câu “mã nguồn có trên GitHub” không thay thế được những bằng chứng này.
Diễn giải việc kiểm tra APK thế nào cho đúng?
- Lấy tệp từ kênh chính thức và với phiên bản xác định.
- Lấy giá trị băm và thông tin người ký từ một nguồn mà bạn tin tưởng về tính xác thực.
- Tính hàm băm của tệp và so sánh với đúng phiên bản đó.
- Khi kiểm tra kỹ thuật, hãy xác thực cả chữ ký; công cụ chính thức apksigner hỗ trợ việc này.
- Nếu thấy khác biệt, hãy dừng cài đặt và làm rõ nguyên nhân; đừng ký lại tệp để vượt qua lỗi.
Ví dụ lệnh kiểm tra dành cho chuyên gia có Android SDK Build Tools:
apksigner verify --verbose --print-certs app.apk
Tên app.apk chỉ là ví dụ. Lệnh thành công không loại bỏ nhu cầu nhận biết khóa hợp lệ của nhà phát hành.
Proof Lab có vai trò gì?
Proof Lab của Livara cung cấp công cụ cho những kiểm tra cụ thể. Hãy đọc phạm vi của từng phép thử: hàm băm tệp, ví dụ thỏa thuận khóa hay từ chối dữ liệu bị sửa là những câu hỏi khác nhau. Một minh họa mật mã thành công không phải là kiểm toán toàn bộ ứng dụng đã cài đặt, máy chủ, bản cập nhật hay quản lý tài khoản.
Mô hình đe dọa của Livara cũng nêu rõ rằng nếu kẻ tấn công thay cả tệp APK lẫn giá trị băm được hiển thị, chỉ việc khớp hàm băm không chứng minh tính xác thực. Đây là giới hạn chung của kiểm tra hàm băm, không phải đặc điểm riêng của một ứng dụng nhắn tin.
Nên hỏi gì khi đọc báo cáo kiểm toán?
- Tổ chức hay những người nào đã thực hiện kiểm tra, và báo cáo công khai ở đâu?
- Phiên bản và commit nào đã được kiểm tra?
- Những phần nào nằm ngoài phạm vi?
- Các phát hiện quan trọng đã được khắc phục và kiểm thử lại thế nào?
- Phiên bản bạn cài đặt có đúng là phiên bản đó hoặc chứa các bản sửa của nó không?
Đừng rút ra kết luận chắc chắn từ những từ như “đã được phê duyệt” khi chưa trả lời các câu hỏi này. Việc dùng thuật toán tiêu chuẩn cũng không tương đương với chứng nhận tiêu chuẩn cho toàn bộ sản phẩm.
Kết luận để chọn ứng dụng nhắn tin
Mã nguồn mở và khả năng kiểm chứng không đối lập nhau; chúng là những bằng chứng bổ sung. Hãy ưu tiên sản phẩm có tuyên bố chính xác, có thể truy xét và phạm vi rõ ràng. Sau đó áp dụng cùng cách kiểm tra cho chế độ bạn sử dụng, như nhóm, phiên bản web, bản sao lưu và thiết bị liên kết, thay vì suy ra an toàn tuyệt đối từ một phép thử thành công.
