Giới thiệu

Trong các cuộc điều tra kỹ thuật số, ngay khi một tệp rời khỏi phương tiện lưu trữ gốc, nó trở nên dễ bị thay đổi không mong muốn. Ngay cả một việc chuyển đổi tưởng như vô hại—đổi ảnh đĩa từ E01 sang RAW, nén một tệp nhật ký, hoặc chuyển đổi PDF để trình bày trong phòng xử án—cũng có thể làm hỏng hàm băm, xóa bỏ dấu thời gian, hoặc phá hủy các thuộc tính ẩn mà sau này lại trở nên quan trọng đối với lời khai của chuyên gia. Bài viết này sẽ hướng dẫn toàn bộ vòng đời chuyển đổi, từ chuẩn bị bằng chứng đến xác minh đầu ra cuối cùng, với trọng tâm vào khả năng tái tạo, khả năng kiểm toán và tính hợp pháp trong pháp luật. Các nguyên tắc được nêu áp dụng cho dù bạn đang làm việc trên một vụ vi phạm công ty, một cuộc tịch thu của lực lượng pháp luật, hay một cuộc kiểm toán nội bộ, và chúng giả định việc sử dụng các công cụ đáng tin cậy, tôn trọng quyền riêng tư như dịch vụ đám mây được cung cấp tại convertise.app khi phù hợp.

1. Thiết lập môi trường chuyển đổi có kiểm soát

Trước khi chạm vào byte đầu tiên, các kiểm toán viên phải khóa chặt môi trường mà quá trình chuyển đổi sẽ diễn ra. Điều này bắt đầu bằng một máy trạm viết‑khóa hoặc một máy trạm pháp y khởi động từ một ảnh pháp y đã được xác nhận là tốt (ví dụ: USB chỉ‑ghi được bảo vệ bằng BitLocker). Tất cả phần mềm được dùng để chuyển đổi phải được kiểm kê, ký kỹ thuật số và kiểm soát phiên bản. Nên ưu tiên các công cụ mã nguồn mở mà hàm băm nhị phân có thể được xác minh, vì các phần mềm đóng nguồn thường mang lại một bề mặt tấn công không được ghi chép. Khi máy trạm đã được cô lập, một thư mục làm việc riêng, được mã hoá, nên được tạo; đường dẫn và quyền truy cập của nó được ghi lại trong nhật ký vụ việc, và thư mục này nên được lưu trên một phương tiện chỉ‑ghi bất cứ khi nào có thể. Những bước này tạo ra một nền tảng có thể tái tạo, giúp dễ dàng chứng minh rằng quá trình chuyển đổi không đưa vào các biến ngoại lai.

2. Ghi lại các hàm băm và siêu dữ liệu cơ sở

Cột mốc của tính toàn vẹn pháp y là giá trị hàm băm (MD5, SHA‑1, SHA‑256, hoặc ưu tiên SHA‑512) được tính trên bằng chứng gốc TRƯỚC khi thực hiện bất kỳ chuyển đổi nào. Việc tính hàm băm phải được thực hiện bằng công cụ tuân thủ tiêu chuẩn NIST SP 800‑90, và giá trị thu được phải được ghi lại cùng với siêu dữ liệu gốc của tệp: dấu thời gian tạo, sửa đổi và truy cập; các thuộc tính hệ thống tệp; và, đối với ảnh đĩa, các chi tiết mức sector như bảng phân vùng và chữ ký hệ thống tệp. Thực hành tốt là ghi lại hàm băm bằng ít nhất hai công cụ băm độc lập, tài liệu hoá bất kỳ sự khác biệt nào như là bằng chứng tiềm năng của việc giả mạo. Hàm băm đã ghi lại trở thành điểm tham chiếu cho mọi bước xác minh tiếp theo.

3. Lựa chọn định dạng đích phù hợp

Không phải mọi chuyển đổi đều tạo ra kết quả giống nhau. Quyết định chuyển đổi nên dựa trên mục tiêu điều tra: bảo tồn, phân tích, hay trình bày. Đối với bảo tồn, định dạng không mất dữ liệu, sector‑bằng‑sector như RAW (dd) hoặc E01 được ưu tiên; chúng giữ nguyên chuỗi byte của phương tiện nguồn. Khi các công cụ phân tích chỉ chấp nhận một container cụ thể (ví dụ: bộ công cụ pháp y chỉ đọc AFF), việc chuyển đổi sang định dạng đó là hợp lý, nhưng bạn vẫn phải giữ một bản sao không chạm tới của tệp gốc. Đối với việc trình bày, tệp PDF‑/A hoặc TIFF có thể phù hợp, tuy nhiên quy trình chuyển đổi phải nhúng một checksum của nguồn vào siêu dữ liệu của tệp đầu ra, tạo liên kết có thể xác minh giữa hai tệp. Lựa chọn một định dạng vốn hỗ trợ siêu dữ liệu (ví dụ: AFF) có thể đơn giản hoá việc liên kết này.

4. Thực hiện chuyển đổi với các dấu vết kiểm toán

Các tiện ích chuyển đổi hiện đại thường cung cấp một log chi tiết ghi lại mọi thao tác, bao gồm đường dẫn nguồn và đích, dấu thời gian, và bất kỳ biến đổi nào được áp dụng (ví dụ: mức nén, độ lấy mẫu ảnh). Khi dùng công cụ dòng lệnh, nên bật tùy chọn --log và lưu file log bên cạnh hiện vật đã chuyển đổi. Nếu quá trình chuyển đổi diễn ra trên dịch vụ đám mây, dịch vụ phải cung cấp một bản ghi kiểm toán bất biến (yêu cầu API có timestamp, hàm băm nguồn, định dạng đích). Bất kể phương pháp nào, kiểm toán viên cần lấy một hàm băm thứ hai trên tệp đã chuyển đổi ngay sau khi quá trình hoàn tất. Hàm băm thứ hai này, cùng với hàm băm gốc, tạo thành một cặp hàm băm có thể được trình bày cho chuyên gia xét nghiệm hoặc thẩm phán sau này.

5. Xác minh tính toàn vẹn sau chuyển đổi

Xác minh không chỉ là so sánh hàm băm đơn giản. Đối với các định dạng không mất dữ liệu, có thể thực hiện so sánh byte‑với‑byte (ví dụ, cmp trên Unix) và nên làm khi định dạng đích cho phép. Đối với các định dạng mất dữ liệu hoặc đã biến đổi, việc xác minh phải tập trung vào việc bảo toàn giá trị chứng cứ: đảm bảo rằng dấu thời gian, EXIF nhúng hoặc các luồng dữ liệu thay thế NTFS, và bất kỳ thuộc tính tệp ẩn nào đều còn tồn tại sau chuyển đổi. Các công cụ như exiftool hoặc fsstat có thể trích xuất và so sánh các thuộc tính này trước và sau chuyển đổi. Mọi sự lệch phải được ghi chép, giải thích, và, nếu có thể, khắc phục (ví dụ, nhúng hàm băm gốc vào siêu dữ liệu của tệp mới bằng thẻ XMP tùy chỉnh).

6. Ghi chép chuỗi quản lý bằng chứng suốt quá trình

Nhật ký chuỗi quản lý bằng chứng là bản ghi theo thời gian của mọi người đã xử lý bằng chứng, mọi thao tác đã thực hiện, và mọi vị trí mà bằng chứng đã lưu trữ. Bước chuyển đổi thêm một nút mới vào chuỗi này. Mục nhập log cho việc chuyển đổi nên bao gồm:

Ngày, giờ và độ lệch UTC của quá trình chuyển đổi.
Tên nhà phân tích và định danh máy trạm.
Lệnh chính xác hoặc yêu cầu API đã dùng.
Hàm băm của tệp nguồn trước khi chuyển đổi.
Hàm băm của tệp kết quả sau khi chuyển đổi.
Lý do chuyển đổi (bảo tồn, phân tích, hay trình bày).
Bất kỳ cài đặt nén hoặc tham số chất lượng nào được áp dụng.

Nhúng thông tin này trực tiếp vào tệp đã chuyển đổi—trong một khối siêu dữ liệu chuyên biệt—tạo ra một hiện vật tự mô tả, có thể được kiểm tra sau này ngay cả khi nhật ký bên ngoài bị mất.

7. Xử lý khối lượng lớn và chuyển đổi hàng loạt

Các vụ điều tra thường liên quan đến hàng trăm gigabyte bằng chứng. Các script chuyển đổi hàng loạt phải quyết đoán và có thể lặp lại. Một mẫu phổ biến là tạo một file manifest (CSV hoặc JSON) liệt kê mỗi tệp nguồn, hàm băm cơ sở và định dạng đích mong muốn. Script đọc manifest, xử lý từng mục, ghi tệp đã chuyển đổi vào thư mục đầu ra được kiểm soát, và thêm một dòng mới vào log kết quả chứa cả hai hàm băm, mã thoát, và bất kỳ cảnh báo nào. Việc quản lý manifest bằng hệ thống kiểm soát phiên bản đảm bảo rằng quá trình chuyển đổi chính xác có thể được thực hiện lại nếu tòa án yêu cầu, đồng thời cho phép kiểm toán viên xác minh rằng không có tệp nào bị bỏ qua hoặc xử lý hai lần.

8. Xử lý bằng chứng được mã hoá hoặc bảo vệ

Các container mã hoá—volume TrueCrypt, ổ đĩa bảo vệ bằng BitLocker, hoặc PDF được đặt mật khẩu—đưa ra một thách thức đặc biệt. Cách tiếp cận pháp y đúng là thu thập container mã hoá ở dạng thô và ghi lại các thông số mã hoá (thuật toán, độ dài khóa, muối) mà không cố gắng giải mã trên máy thu thập. Nếu cần giải mã để phân tích, việc này nên được thực hiện trên một hệ thống cô lập, không kết nối mạng, sau khi khóa giải mã đã được ghi chép và xác thực đầy đủ. Khi đã giải mã, tệp bản rõ có thể được chuyển đổi, nhưng cả bản gốc mã hoá và bản sao đã giải mã đều phải được bảo quản, mỗi bản có hàm băm riêng, để duy trì chuỗi bằng chứng.

9. Các cân nhắc pháp lý và tính chấp nhận

Tòa án sẽ xem xét mọi chuyển đổi của bằng chứng kỹ thuật số. Để đáp ứng các tiêu chuẩn chấp nhận (ví dụ: Daubert, Frye), quy trình chuyển đổi phải:

Khoa học vững chắc: dựa trên các công cụ và phương pháp được chấp nhận rộng rãi.
Minh bạch: mọi bước đều được ghi chép đầy đủ và có thể tái tạo.
Đã được xác thực: kết quả của công cụ đã được kiểm chứng so với các mẫu đã biết.
Độc lập: tốt nhất là được một nhà phân tích thứ hai hoặc một đánh giá đồng nghiệp bên ngoài xác nhận.

Khi chuyển đổi được thực hiện bằng dịch vụ đám mây của bên thứ ba, nhà điều tra nên có được một Thỏa thuận Dịch vụ (SLA) bao gồm các điều khoản xử lý dữ liệu, và lưu giữ các tài liệu chứng nhận (ISO 27001, SOC 2) cho thấy nhà cung cấp cam kết bảo mật và tính toàn vẹn.

10. Lưu trữ lưu trữ (archival) cho bằng chứng đã chuyển đổi

Sau khi chuyển đổi, hiện vật nên được lưu trữ trong một kho lưu trữ bằng chứng áp dụng chính sách chỉ‑ghi, đọc‑nhiều (WORM). Kho này phải duy trì cặp hàm băm cho mỗi tệp, và phương tiện lưu trữ cần được kiểm tra định kỳ bằng việc kiểm tra tính cố định (re‑hash) để phát hiện sự hư hỏng bit. Nếu kho hỗ trợ versioning, tệp gốc và mỗi bản chuyển đổi nên được coi là các phiên bản riêng, mỗi phiên bản có bản ghi siêu dữ liệu bất biến của riêng mình. Thực hành này đảm bảo rằng những người xem trong tương lai có thể truy vết nguồn gốc của một hiện vật từ việc thu thập thô đến mọi biến đổi tiếp theo.

11. Tóm tắt danh sách kiểm tra thực hành tốt nhất

Cô lập máy trạm chuyển đổi và dùng viết‑khóa nếu có thể.
Ghi lại hàm băm cơ sở và toàn bộ siêu dữ liệu trước bất kỳ biến đổi nào.
Lựa chọn định dạng đích phù hợp với mục tiêu điều tra và bảo toàn các thuộc tính quan trọng.
Bật log chi tiết hoặc dấu vết kiểm toán cho mọi lệnh chuyển đổi hoặc yêu cầu API.
Tính hàm băm sau chuyển đổi và so sánh với kế hoạch xác minh đã định trước.
Ghi chép bước chuyển đổi một cách kỹ lưỡng trong nhật ký chuỗi quản lý bằng chứng, đồng thời nhúng các chi tiết chính vào tệp itself.
Sử dụng manifest quyết đoán cho xử lý hàng loạt và giữ chúng dưới kiểm soát phiên bản.
Xem các container mã hoá như bằng chứng riêng; chỉ giải mã khi thực sự cần thiết và giữ cả bản mã hoá và bản giải mã.
Xác thực đầu ra của công cụ chuyển đổi với dữ liệu kiểm tra đã biết và nhận được xác nhận từ đồng nghiệp.
Lưu trữ các hiện vật đã chuyển đổi trong kho đáp ứng WORM và thực hiện kiểm tra tính cố định định kỳ.

Việc tuân thủ các bước này biến một công việc chuyển đổi tệp thông thường thành một quy trình pháp y hợp lệ, bảo toàn trọng lượng chứng cứ của các hiện vật kỹ thuật số từ lúc bị tịch thu cho tới khi được trình bày trước tòa án.

Chuyển đổi tệp pháp y kỹ thuật số: Bảo đảm tính toàn vẹn của bằng chứng