Giải thích chính xác về mã hóa và lỗ hổng Android

Lưu ý: Chà, tiền thưởng đã hết hạn và một lý do có thể là nỗ lực cần thiết để giải quyết khi tôi thu thập từ các bình luận. Nhìn thấy số lượng upvote, nó dường như cũng được người khác quan tâm. Tôi vẫn muốn nhận được câu trả lời vì vậy đây là những gì tôi đề xuất - một câu trả lời tốt trong vòng một tháng, sẽ nhận được tiền thưởng là 50. Điều này tôi hy vọng sẽ cung cấp đủ thời gian và khuyến khích

Tôi đã cố gắng tìm hiểu quy trình Mã hóa Android và các lỗ hổng của nó trong một thời gian

Có rất nhiều câu hỏi giải quyết các phần của chủ đề này trên trang web này và cả trên trang web chị em. Để lái xe về nhà quan điểm của tôi, những câu hỏi giải quyết phần và không phải toàn bộ (gợi nhớ đến " người mù và một con voi ?" :)

• Mã hóa Marshmallow bảo vệ là gì?
• Mã hóa thiết bị đầy đủ có bảo vệ dữ liệu của tôi khỏi Google và chính phủ không?
• /android/137334/if-we-encrypt-our-device-can-user-connecting-to-adb-get-it
• Các câu hỏi liên quan đến mã hóa thẻ SD
• mã hóa android-khi-điện thoại là trên
• android-cyanogenmod-mã hóa-vs-gnu
• is-there-cryptographic-liệu-in-a-phone-sim-card-that-can-be-used-with-rsa
• mã hóa thiết bị android

Sự hiểu biết của tôi (hoặc hiểu lầm?)

1. Mật khẩu mã hóa được tạo từ sự kết hợp giữa mã PIN màn hình khóa người dùng và thuật toán mã hóa (trong đó có một điểm yếu cố hữu do độ dài giới hạn của mã PIN)
2. Đây là muối và được lưu trữ trong vị trí gốc, người dùng không thể truy cập
3. Điều này được sử dụng để tạo mật khẩu thực tế để mã hóa / giải mã và mật khẩu thực được lưu trữ trong RAM
4. Điều này đã được củng cố bằng cách liên kết Bước 1 với thiết bị SoC ( Phiên bản Android nào? Phần tử phần cứng nào nhận dạng duy nhất thiết bị? Điều đó có thể được thay thế thành giả không? )
5. Do đó, không thể giải mã dữ liệu nếu không có khóa mã hóa và thiết bị (cũng giữ cho SD bên ngoài)
6. Các phương pháp phục hồi có thể - lực lượng vũ phu, nắm bắt thông tin RAM (bước 3) để lấy khóa
7. Các thiết bị đã root dường như dễ truy cập dữ liệu của bước 2 hơn thông qua phục hồi tùy chỉnh / có thể là ROM và flash kernel ?? ( nếu đúng, tại sao điều này không được coi là rủi ro lớn? )
8. Ngay cả khi thông tin này có được, tôi đoán rằng đó là nỗ lực không hề nhỏ để tạo mật khẩu thực tế
9. Marshmallow có thể coi SD bên ngoài là "bộ nhớ trong" hoặc "bộ lưu trữ di động". Theo logic, nó không nên tạo ra sự khác biệt nhưng không chắc chắn

Có những lỗ hổng trong sự hiểu biết của tôi, có lẽ cũng bỏ lỡ các khía cạnh quan trọng khác.

Vì vậy, tôi đang tìm kiếm một lời giải thích kinh điển để hiểu từ góc độ người dùng

• Toàn bộ quá trình mã hóa (bao gồm SD bên ngoài)

• Biến thể triển khai trên các phiên bản Android - từ KitKat đến Marshmallow (bao gồm các tùy chọn kép cho SD bên ngoài trong Marshmallow)

• Lỗ hổng ở cấp độ người dùng

Ghi chú

• Tôi nhận thức được nguy cơ câu hỏi bị coi là quá rộng nhưng IMO đảm bảo điều trị toàn diện

• Có một số kinh nghiệm về bảo mật truyền thông, tôi hiểu thách thức trong việc dịch các khái niệm về Mật mã sang cấp độ người dùng. Tôi muốn câu trả lời để giải quyết vấn đề này, với con trỏ giải thích để hiểu sâu hơn. Các ví dụ về quy trình không cần phải đúng về mặt mật mã theo nghĩa chặt chẽ mà phải truyền tải được bản chất

• Một lợi thế có thể là "đánh lừa" các câu hỏi trong tương lai về các khía cạnh liên quan

• Với chi phí lặp lại, câu trả lời nên chủ yếu ở cấp độ người dùng , nhưng với lời giải thích đầy đủ để hiểu sâu hơn. Chia câu trả lời thành hai phần có thể là một cách phù hợp.

• Tôi sẽ làm cho nó một điểm để bỏ phiếu trả lời công việc tầm thường / ngẫu nhiên / vá để khuyến khích câu trả lời toàn diện

Tôi hình dung nó hoạt động như thế này:

• Lưu trữ được mã hóa bằng khóa ngẫu nhiên đồng bộ.
• Khi người dùng chọn hoặc thay đổi mật khẩu dựa trên bất kỳ đầu vào nào, có thể là mật khẩu bao gồm các chữ cái và số và ký tự hoặc có thể là mã pin, hoặc vuốt mẫu hoặc in dấu vân tay hoặc bất kỳ đầu vào nào khác, mã hóa không đồng bộ thuật toán được sử dụng để mã hóa khóa chính, sao cho việc xác định chính xác kết thúc việc giải mã đầu vào dẫn đến khóa chính, từ đó giúp mã hóa và giải mã lưu trữ.
• Khoảnh khắc người dùng đăng xuất, bộ nhớ giữ khóa chính bị ghi đè

Thủ thuật lớn ở đây là mã hóa không đồng bộ của khóa chính. Khi Android có khóa chính, nó có khả năng trao đổi dữ liệu với bộ lưu trữ. Chỉ khi người dùng đăng nhập, khóa chính đó mới được biết. Mã hóa không đồng bộ là những gì được gọi là mã hóa khóa công khai. Điều xảy ra là khóa công khai mã hóa dữ liệu (khóa chính trong trường hợp này) và khóa riêng giải mã dữ liệu. Không nên nhầm lẫn với mã hóa lưu trữ ở đây. Việc lưu trữ chỉ là mã hóa đồng bộ. Có cùng khóa được sử dụng để mã hóa và giải mã. Nhưng việc tìm kiếm / truy xuất khóa "chính" đó là vấn đề lớn. Điều đó có nghĩa là nếu tại một thời điểm, bạn có một phương thức đăng nhập yếu, như đối với intance "1234" là một chốt, và bạn thay đổi ý định, và thay đổi mã pin thành "5364", khó đoán hơn, trừ khi trước đó "1234 " đã bị đánh cắp, rình mò, tại bất kỳ thời điểm nào, an ninh đã trở nên tốt hơn. Thỏa thuận tương tự khi thay đổi phương thức đăng nhập thành mật khẩu đầy đủ không thể đoán hoặc tấn công từ điển. Bản thân bộ lưu trữ không cần phải mã hóa lại. Đó là tất cả về việc ẩn khóa chủ đó - trong nội bộ. Người dùng không bao giờ nhìn thấy khóa chính đó, bởi vì rất có thể đó chỉ là một mã băm ngẫu nhiên của các loại - không có gì sẽ "tìm thấy" hoặc "đoán" mã băm đó. Ngay cả NSA hay bất kỳ cơ quan an ninh nào khác trên hành tinh cũng không thể tìm thấy khóa phù hợp như thế. Vectơ tấn công duy nhất đang hy vọng cho một điểm yếu về phía người dùng. Có lẽ người dùng đã chọn đăng nhập pincode. Nếu đó là 4 chữ số, thì đó là tối đa 10000 mã có thể. HĐH có thể "chặn" thiết bị sau khi dùng thử một vài lần trong một thời gian ngắn. Giải pháp sau đó là "hack" HĐH, để có thể thử tất cả các mã khóa có thể mà không cần HĐH can thiệp và chặn thiết bị. Tôi tin rằng đó là cách cuối cùng FBI có quyền truy cập vào điện thoại của một tên tội phạm. Tôi nghĩ rằng một công ty bên thứ ba (một số công ty Israel từ những gì tôi nhớ lại) đã hack cho FBI. Họ đã bỏ qua giới hạn thử pincode đó. Nếu thông tin đăng nhập là mật khẩu đầy đủ và nếu người dùng chọn mật khẩu mạnh và bạn sẽ thấy. Không phải trong một cuộc sống với tất cả sức mạnh cpu trên hành tinh sẽ hack điều đó trong một triệu năm. Tôi không mua bất kỳ NSA nào có thể giải mã mọi tin đồn. Tôi nghĩ những người đó đã xem quá nhiều phim về những người đàn ông mặc đồ đen. Tất cả mọi người phải làm là xem các tài liệu khoa học về các thuật toán mã hóa khác nhau (ví dụ: AES) và bạn sẽ biết rằng việc hack đơn giản sẽ không xảy ra, ngoại trừ vào thời xa xưa khi có các phím 40 bit. Ngày xưa ấy nay còn đâu. AES128 tôi nghĩ là không thể thiếu, và nếu có ai quan tâm, việc nhảy lên AES256 khiến nó an toàn hơn bởi độ lớn của kích thước vũ trụ khá nhiều. Có thể một ngày nào đó máy tính lượng tử có thể giải mã nó, nhưng tôi nghi ngờ. Không chắc chắn nếu có thể có một hệ thống xác suất chỉ cần làm nổi bật giải pháp. Cuối cùng chúng ta sẽ thấy điều đó. Có lẽ đó là một vài kiếp nữa. Không có gì phải lo lắng ngay bây giờ.

Vì vậy, cuối ngày, giới hạn bảo mật nằm hoàn toàn trên phương thức đăng nhập được sử dụng. Người ta có thể thay đổi phương thức mà không phải mã hóa lại bộ nhớ. Tất cả điều này là do mã hóa khóa công khai không đồng bộ của khóa chính.

Vì các bản cập nhật là thường xuyên, cách mã hóa trên điện thoại (HĐH dựa trên Android) được xử lý có thể thay đổi từ bản dựng này sang bản dựng tiếp theo. Do đó, mối quan tâm chính không phải là bản thân mã hóa, mà là quá trình đang chạy. Và nếu nền tảng đó có lỗ hổng, thì sức mạnh của thuật toán mã hóa tự nó trở nên ít hoặc không quan trọng.

Về cơ bản, một khi thiết bị của bạn giải mã (các) tệp, chúng có thể được truy cập trực tiếp bằng một quy trình với các đặc quyền Siêu người dùng. Quá trình này có thể có quyền truy cập vào thiết bị của bạn bằng cách khai thác điểm yếu trong chính ROM (HĐH Android). (Điều này gần đây đã có trong tin tức khi một số lỗ hổng đã được WikiLeaks tiết lộ)

Các thiết bị đã root dường như dễ truy cập dữ liệu bước 2 hơn thông qua phục hồi tùy chỉnh / có thể là ROM và flash kernel ?? (nếu đúng, tại sao điều này không được coi là rủi ro lớn?)

Trước khi root : Để root thiết bị, bạn phải sử dụng các công cụ bên ngoài, tất cả đều có quyền truy cập sâu vào cấu trúc bên trong của thiết bị. Một số trong các công cụ này được biên dịch trước và không phải là nguồn mở. Họ có trang web "chính thức", nhưng những người này là ai? (twrp.me, supersu.com chẳng hạn, nhưng có những người khác như KingoRoot) Chúng ta có thể thực sự tin tưởng họ không? Tôi tin tưởng một số hơn những người khác. Ví dụ, KingoRoot đã cài đặt một chương trình trên máy tính của tôi hoạt động theo kiểu giống như vi-rút (phải sử dụng khởi động kép để loại bỏ nó).

Sau khi bạn root : cung cấp cho một chương trình được biên dịch (APK) quyền truy cập SU có nghĩa là nó có thể làm bất cứ điều gì nó muốn mà không bị hạn chế hoặc nêu rõ ý định mà nó sẽ sử dụng. (Ý định là cách để APK truy cập vào những thứ như WiFi, Camera, v.v.) Vì vậy, một "ứng dụng đáng tin cậy", sau khi có quyền truy cập root, có thể dễ dàng truy cập bất kỳ loại thông tin nào và gửi lại cho máy chủ của nó.

Mã hóa thiết bị đầy đủ có bảo vệ dữ liệu của tôi khỏi Google và chính phủ không?

Google - vâng. Nó không có chìa khóa để mở khóa.

Chính phủ (hoặc tin tặc) - không. bởi vì Chính phủ hoặc tin tặc về cơ bản có thể sử dụng một khai thác sẽ chặn (các) tệp như tôi đã đề cập ở trên.

Sự phức tạp của các thủ tục / thuật toán bảo mật ít được sử dụng nếu chúng có thể bị chặn và bỏ qua.

Chỉnh sửa: Điều đáng nói là Google thực sự có khả năng tải xuống và cài đặt / cập nhật ứng dụng trên thiết bị Android của bạn mà không cần xin phép bạn, hoặc thậm chí thông báo cho bạn rằng việc cập nhật đã diễn ra. Và ngay cả trên thiết bị đã root, dường như không có cách nào để chặn điều này mà không mất các chức năng chính (Play Store, Bản đồ, Đồng bộ hóa, v.v.)