Kiến trúc Bảo mật: Ngăn xếp kỹ thuật đầy đủ

Vaultaire dùng AES-256-GCM để mã hóa có xác thực cho chỉ mục két, khóa đã bọc, tiêu đề tệp, nội dung, ảnh thu nhỏ và siêu dữ liệu. PBKDF2-HMAC-SHA512 tạo khóa két trên máy từ mẫu hình và muối chung của thiết bị trong Keychain. Khóa két đó bọc một khóa chính 256 bit ngẫu nhiên riêng, dùng để mã hóa tệp qua CryptoKit trong tiến trình ứng dụng.

Ngăn xếp mật mã

Vaultaire dùng nhiều cơ chế mật mã phối hợp với nhau, mỗi cơ chế được chọn cho một việc cụ thể. PBKDF2 biến thông tin xác thực của con người thành khóa két hoặc khóa khôi phục. AES-256-GCM bảo vệ chỉ mục, lớp bọc khóa, siêu dữ liệu, ảnh thu nhỏ và nội dung tệp. Khóa chính ngẫu nhiên tách việc mã hóa tệp lâu dài khỏi mẫu hình, vốn có thể thay đổi. Keychain và Bảo vệ dữ liệu của iOS bảo vệ bản ghi khôi phục và muối gắn với thiết bị khi thiết bị bị khóa. Không có khóa giải mã nào do nhà cung cấp giữ để nhà phát triển thường xuyên truy cập được bản rõ của két.

Đây không phải là sự phức tạp cho có. Mỗi lớp xử lý một bề mặt tấn công khác nhau. AES-256-GCM kết hợp tính bảo mật với xác thực, nên bản mã bị sửa đổi sẽ không qua được bước xác minh. PBKDF2 làm tăng chi phí thử từng mẫu hình hoặc cụm từ. Khóa chính ngẫu nhiên nghĩa là khi đổi mẫu hình, ứng dụng chỉ cần bọc lại một khóa thay vì mã hóa lại mọi tệp. Bảo vệ dữ liệu Keychain bảo vệ bản ghi khôi phục và muối trên máy, còn ứng dụng vẫn thừa nhận rằng mã hóa đối xứng diễn ra trong bộ nhớ tiến trình.

Các lớp này cùng tạo thành một kiến trúc phòng thủ nhiều lớp, nhưng không phải lớp nào cũng là một rào cản độc lập. Một mẫu hình phỏng đoán có thể được kiểm tra dựa vào tên tệp chỉ mục và xác thực AES-GCM, và một thiết bị đã mở khóa bị xâm nhập có thể quan sát khóa hoặc bản rõ trong tiến trình ứng dụng. Vì vậy, kiến trúc này phụ thuộc vào entropy của thông tin xác thực, chi phí PBKDF2, lớp bảo vệ thiết bị của iOS và việc xử lý đúng mã hóa có xác thực, cũng như vào độ mạnh của chính AES.

AES-256-GCM: Mã hóa tệp

Mọi ảnh, video và tài liệu lưu trong Vaultaire đều được mã hóa bằng AES-256-GCM, tức Tiêu chuẩn mã hóa nâng cao với khóa 256 bit ở chế độ Galois/Counter. Vaultaire cũng dùng AES-GCM cho chỉ mục két, tiêu đề tệp, ảnh thu nhỏ và phong bì khóa. Thuật toán và kích thước khóa đã được chuẩn hóa; bảo mật của Vaultaire vẫn phụ thuộc vào việc xử lý nonce, quản lý khóa, độ mạnh của thông tin xác thực và tính đúng đắn của phần triển khai.

“256” trong AES-256 đề cập đến độ dài khóa tính bằng bit. Khóa 256 bit có 2²⁵⁶ giá trị có thể có. Để dễ hình dung con số đó: có khoảng 10⁸⁰ nguyên tử trong vũ trụ quan sát được. Nếu mỗi nguyên tử là một siêu máy tính đang kiểm tra một tỷ khóa mỗi giây, chạy kể từ Vụ nổ lớn, thì chúng sẽ khám phá chưa đến một phần nghìn tỷ của một phần nghìn tỷ của một phần trăm không gian khóa. AES-256 sẽ không bị ép buộc một cách thô bạo. Không phải hôm nay. Không phải thế kỷ này. Không phải trước khi các ngôi sao cháy hết.

Tại sao Chế độ GCM lại quan trọng

AES là mật mã khối, nó mã hóa dữ liệu theo khối 128 bit. “mode” xác định cách kết hợp các khối đó. GCM (Chế độ Galois/Bộ đếm) cung cấp hai thứ mà các chế độ đơn giản hơn như CBC không có: mã hóa song song và xác thực tích hợp.

Phần xác thực rất quan trọng. GCM tạo thẻ mật mã cho mọi tệp được mã hóa. Thẻ này hoạt động như một con dấu giả mạo. Nếu ngay cả một bit của văn bản mã hóa bị sửa đổi, cho dù do tác nhân độc hại hay khu vực đĩa bị hỏng, thì thẻ xác thực sẽ không khớp và quá trình giải mã sẽ không thành công. Bạn không nhận được dữ liệu bị hỏng. Bạn nhận được một tín hiệu rõ ràng rằng có điều gì đó không ổn. Thuộc tính này được gọi là mã hóa xác thực và nó ngăn chặn toàn bộ lớp tấn công trong đó đối thủ sửa đổi dữ liệu được mã hóa để thao túng đầu ra được giải mã.

PBKDF2: Đạo hàm chính

Vaultaire tạo các khóa khác nhau cho các việc khác nhau. Mẫu hình và muối chung của thiết bị trong Keychain được đưa vào PBKDF2-HMAC-SHA512 với 600.000 vòng lặp để tạo khóa két trên máy. Một phép tạo khóa cố định từ mẫu hình cho ra khóa sao lưu đám mây riêng. Cụm từ khôi phục đã chuẩn hóa chạy qua 800.000 vòng lặp PBKDF2 để tạo khóa cho phong bì khôi phục. Không phép tạo khóa nào trong số đó biến thông tin xác thực của con người thành 256 bit entropy chỉ vì đầu ra dài 256 bit.

PBKDF2 bảo vệ mẫu của bạn như thế nào

Ý tưởng cốt lõi của PBKDF2 là cố ý bắt máy làm việc nhiều. Nó lấy mẫu hình đã tuần tự hóa hoặc cụm từ đã chuẩn hóa và chạy hàng trăm nghìn vòng lặp HMAC-SHA512. Người dùng hợp lệ trả chi phí đó một lần cho mỗi lần mở khóa hoặc khôi phục. Kẻ tấn công phải trả chi phí đó cho mọi phỏng đoán, dù cách triển khai và phần cứng song song quyết định tốc độ đoán thực tế.

Vaultaire cấu hình PBKDF2 với 600.000 vòng lặp cho các khóa tạo từ mẫu hình. Điều đó khiến mỗi lần đoán tốn kém hơn, nhưng một ước tính tấn công có trách nhiệm phải nêu rõ giả định về phần cứng và thời gian đo được cho mỗi phỏng đoán. Với đúng 1 ms cho mỗi phỏng đoán, 1.000.000.000 lần đoán nối tiếp mất khoảng 11,6 ngày, không phải nhiều năm. Đầu ra 256 bit không làm tăng entropy của một mẫu hình dễ đoán.

Việc tạo khóa từ mẫu hình trên máy dùng một muối ngẫu nhiên an toàn về mật mã cho thiết bị, lưu dưới dạng mục Keychain WhenUnlockedThisDeviceOnly. Muối này không bí mật và được dùng chung cho các két trên thiết bị đó. Nó ngăn các bảng dựng sẵn cho một thiết bị dùng thẳng được cho thiết bị khác có muối khác, nhưng không buộc kẻ tấn công phải làm lại từ đầu cho từng két trên cùng một thiết bị.

AES-256-GCM: bảo vệ siêu dữ liệu

Mã hóa nội dung tệp là chưa đủ. Tên tệp, ngày tạo, kích thước hình thu nhỏ và cấu trúc két đều là siêu dữ liệu, và siêu dữ liệu có thể hiển thị giống như chính dữ liệu đó. Tệp có tên “tax-return-2025.pdf” cho kẻ tấn công biết chính xác những gì bên trong ngay cả khi nội dung được mã hóa. Dấu thời gian hiển thị khi bạn sử dụng vault. Kích thước hình thu nhỏ cho biết nội dung nào đó là ảnh hay video.

Vaultaire bảo vệ siêu dữ liệu này bằng AES-256-GCM, không phải ChaCha20. Tên tệp và loại MIME được mã hóa trong tiêu đề tệp đã mã hóa. Chỉ mục két đã mã hóa chứa bản ghi tệp, ngày tháng, thông tin kích thước, bố cục lưu trữ và khóa chính đã bọc. Dữ liệu ảnh thu nhỏ cũng được mã hóa bằng khóa chính ngẫu nhiên.

Vì sao siêu dữ liệu cần mã hóa có xác thực?

Siêu dữ liệu cần cả tính toàn vẹn lẫn tính bảo mật. AES-GCM tạo thẻ xác thực cho từng giá trị đã mã hóa, nên Vaultaire có thể từ chối tiêu đề, chỉ mục, ảnh thu nhỏ hoặc phong bì bị sửa đổi thay vì chấp nhận bản rõ do kẻ tấn công kiểm soát. Thiết kế này cố ý dùng một cấu trúc mã hóa có xác thực cho các định dạng lưu trữ đó, thay vì tuyên bố sự đa dạng về mật mã mà phần triển khai không có.

Dùng cùng một thuật toán mã hóa không có nghĩa là dùng lại khóa hoặc nonce một cách mù quáng. Khóa két bảo vệ chỉ mục và bọc khóa chính ngẫu nhiên; khóa chính bảo vệ dữ liệu tệp. CryptoKit tạo các hộp niêm phong có xác thực với nonce mới, còn định dạng truyền luồng của Vaultaire tạo một nonce riêng cho từng đoạn theo thứ tự. Các bảo đảm liên quan đến từ việc tách khóa, kỷ luật dùng nonce và xác thực, không phải từ một thuật toán mã hóa siêu dữ liệu thứ hai.

Mã hóa

Đây là câu hỏi đáng đặt ra về bất kỳ ứng dụng bảo mật nào: điều gì sẽ xảy ra nếu công ty đứng sau ứng dụng đó bị hack, bị triệu tập hoặc đơn giản là trở nên độc hại?

Với hầu hết các ứng dụng, câu trả lời là không thoải mái. Chúng chứa dữ liệu, chìa khóa của bạn hoặc cả hai. Lệnh của tòa án buộc họ phải giao nó. Một vi phạm dữ liệu cho thấy nó. Một nhân viên lừa đảo truy cập nó. Bảo mật của ứng dụng’ chỉ mạnh bằng bảo mật hoạt động ’ của công ty, và lịch sử cho thấy các công ty thường xuyên bị vi phạm.

Vaultaire không vận hành tài khoản hay dịch vụ lưu trữ nào nhận mẫu hình, cụm từ bí mật, khóa giải mã hoặc nội dung két đọc được của bạn. Việc mã hóa và giải mã diễn ra trong tiến trình ứng dụng trên thiết bị của bạn. Khi sao lưu iCloud được bật, ứng dụng gửi bản mã có xác thực tới cơ sở dữ liệu CloudKit riêng tư của bạn, không gửi tới dịch vụ két do Vaultaire kiểm soát.

Zero-knowledge có ý nghĩa gì trong thực tế

Nếu cơ quan thực thi pháp luật gửi Vaultaire trát đòi bản rõ của két, công ty không giữ mẫu hình, cụm từ khôi phục, khóa két, khóa sao lưu hay khóa chính cần để giải mã. Bản ghi iCloud đã mã hóa nằm trong cơ sở dữ liệu CloudKit riêng tư của người dùng. Tuy vậy, trên thiết bị, dữ liệu khôi phục được giữ trong một cơ sở dữ liệu Keychain đã mã hóa, và các khóa đối xứng nằm trong bộ nhớ ứng dụng khi CryptoKit mã hóa hoặc giải mã một két đang mở.

Ranh giới nhà cung cấp này là một đặc tính kiến trúc, không phải lời hứa rằng mọi phần của môi trường máy khách đều nằm ngoài mô hình tin cậy. Vaultaire không giữ khóa giải mã phía máy chủ nào mà công ty có thể giao nộp để khôi phục két theo cách thông thường. Ứng dụng đã phát hành, iOS, thiết bị đã mở khóa và phần triển khai mật mã vẫn có thể xử lý dữ liệu đọc được, nên cũng phải được tin cậy tương ứng.

Keychain và ranh giới tiến trình ứng dụng

Secure Enclave của Apple có thể bảo vệ các khóa riêng tư được hỗ trợ và tham gia vào một số phần của kiến trúc bảo mật nền tảng, nhưng API công khai của nó không nhận khóa đối xứng tùy ý tạo từ PBKDF2 và không thực hiện các thao tác tệp AES-GCM của Vaultaire bên trong bộ đồng xử lý đó. Vì vậy, Vaultaire không mô tả phần mật mã của két là AES trong Secure Enclave.

Vaultaire dùng các mục mật khẩu chung thông thường trong Keychain của iOS cho muối ngẫu nhiên của thiết bị, cơ sở dữ liệu khôi phục đã mã hóa và khóa ngẫu nhiên bảo vệ cơ sở dữ liệu đó. Các mục này dùng lớp truy cập WhenUnlockedThisDeviceOnly. Keychain và Bảo vệ dữ liệu tạo ra một ranh giới thiết bị có ý nghĩa, nhất là khi điện thoại bị khóa, nhưng kiến trúc này khác với khóa Secure Enclave không thể xuất ra.

Khi bạn vẽ mẫu hình, CommonCrypto tạo khóa két trong tiến trình ứng dụng. Sau đó CryptoKit và CryptoEngine của Vaultaire dùng các byte khóa đối xứng trong tiến trình đó để xác thực và giải mã chỉ mục, mở khóa chính và xử lý tệp. Ứng dụng xóa trạng thái đang hoạt động khi khóa két, nhưng kẻ tấn công có đủ đặc quyền để quan sát một phiên đã mở khóa có cơ hội khác với người kiểm tra chỉ có bản mã từ một thiết bị bị khóa.

Hệ điều hành đã jailbreak hoặc bị xâm nhập có thể nhắm vào thao tác nhập mẫu hình, bộ nhớ ứng dụng, bản xem trước đã giải mã, dữ liệu xuất ra hoặc màn hình. Vaultaire khuyên dùng iPhone đã cập nhật và chưa jailbreak, vì thiết kế dựa vào cơ chế cách ly tiến trình, Keychain và Bảo vệ dữ liệu của iOS. Vaultaire không khẳng định rằng khi quyền root bị xâm nhập, các khóa đối xứng của két đang mở vẫn không thể bị truy cập.

Các vectơ khởi tạo: cho mỗi tệp

Khi bạn mã hóa hai tệp giống hệt nhau bằng cùng một khóa, việc triển khai đơn giản sẽ tạo ra văn bản mã hóa giống hệt nhau. Đây là một vấn đề. Kẻ tấn công nhìn thấy hai đốm màu được mã hóa giống hệt nhau sẽ biết, mà không cần giải mã bất cứ điều gì, rằng hai tệp gốc giống nhau. Trong một kho chứa đầy ảnh, kiểu phân tích mẫu này có thể tiết lộ thông tin ngay cả khi thông qua mã hóa.

Vaultaire tránh tạo bản mã có thể đoán trước bằng cách tạo một nonce mới cho mỗi thao tác niêm phong AES-256-GCM. Tiêu đề tệp và nội dung tệp được niêm phong riêng, và tệp lớn dùng định dạng truyền luồng có xác thực với nonce gốc ngẫu nhiên và nonce riêng cho từng đoạn theo thứ tự. Vì vậy, hai bản sao của cùng một bức ảnh không cho ra cùng một bản mã.

Nonce được lưu cùng bản mã và không bí mật; yêu cầu bảo mật đối với nonce là không được trùng lặp dưới cùng một khóa. Vaultaire lấy nonce 96 bit từ bộ tạo số ngẫu nhiên mật mã của Apple cho mỗi lần mã hóa đơn lẻ và ghi nonce gốc vào tiêu đề truyền luồng. Rủi ro trùng nonce phụ thuộc vào số lần mã hóa dưới một khóa, nên phần triển khai tạo giá trị mới mỗi lần thay vì coi kích thước 96 bit là một bảo đảm cố định với xác suất 1 trên 2⁹⁶ suốt vòng đời.

Quản lý bộ nhớ: xóa trạng thái khóa đang hoạt động

Một lỗi phổ biến trong phần mềm bảo mật là để lại dữ liệu nhạy cảm trong bộ nhớ sau khi không còn cần thiết nữa. Khóa mã hóa, mật khẩu phái sinh và dữ liệu được giải mã có thể tồn tại trong RAM rất lâu sau khi ứng dụng sử dụng xong chúng. Các công cụ pháp y có thể kết xuất bộ nhớ thiết bị và tìm kiếm những phần còn sót lại, một kỹ thuật được gọi là tấn công khởi động nguội hoặc phân tích kết xuất bộ nhớ.

Vaultaire giới hạn thời gian giữ trạng thái khóa đang hoạt động và dữ liệu giao diện đã giải mã. Khi ứng dụng khóa két hoặc phiên bị hủy, mã của ứng dụng đi theo một số luồng dọn dẹp:

• Trạng thái két đang hoạt động bị loại bỏ. Ứng dụng xóa phiên khóa két hiện tại và yêu cầu mở khóa lại trước khi hiện nội dung két.
• Lớp bọc khóa xóa bộ đệm mà chúng sở hữu. Các vùng chứa byte bảo mật của Vaultaire ghi đè bộ đệm của chúng khi được giải phóng.
• Trạng thái khóa chính trong bộ nhớ đệm bị vô hiệu. Khóa chính đã giải mã được giữ cho chỉ mục đang mở bị loại bỏ trong các luồng khóa két và luồng đặt lại bộ đệm liên quan.
• Bộ nhớ đệm giao diện đã giải mã được xóa ở những nơi Vaultaire kiểm soát. Việc dọn ảnh thu nhỏ và bản xem trước giúp giảm trạng thái còn sót lại trong ứng dụng, nhưng ứng dụng không kiểm soát được mọi bản sao do Swift, iOS hay một tiến trình khác tạo ra.

Lần tới Vaultaire mở ở trạng thái khóa, bạn vẽ mẫu hình và ứng dụng tạo lại khóa két trước khi có thể xác thực chỉ mục và mở khóa chính. Đây là việc dọn dẹp phiên, không phải lời khẳng định rằng mọi bản sao tạm thời trong bộ nhớ đều được xóa nhiều lượt một cách chứng minh được, hay rằng một tham chiếu khóa trong Secure Enclave đã bị hủy. Khi ứng dụng bị treo, iOS thu hồi tiến trình, nhưng mã dọn dẹp không thể chạy sau mọi lần bị dừng đột ngột.