Có an toàn hợp lý để sử dụng mã PIN để mã hóa?


19

Trên Android 4.0 (Samsung Galaxy Nexus) có khả năng mã hóa điện thoại. Tôi thấy điều này về mã hóa trên Android 3.0, có phải là thuật toán tương tự được sử dụng trong Android 4 không? http://source.android.com/tech/encoding/android_crypto_im THỰCation.html

Câu hỏi chính của tôi liên quan đến việc sử dụng mã PIN để giải mã điện thoại của bạn. Tại sao tôi buộc phải sử dụng cùng một mật khẩu để mở khóa màn hình và giải mã điện thoại của mình? Hạn chế này sẽ chỉ cho phép tôi sử dụng mật khẩu có độ phức tạp thấp (như số PIN) vì sẽ khó viết vào tức là 17 ký tự để mở khóa điện thoại cho một cuộc gọi điện thoại đơn giản.

Có thể ngăn chặn các nỗ lực vũ phu đối với việc mở khóa màn hình, tức là bằng cách khởi động lại lực lượng cứ sau 5 lần thử. Vì vậy, không cần bất kỳ mật khẩu mạnh nào ở đó, mã PIN có thể đủ tốt.
Loại bảo vệ này không thể được sử dụng trên đĩa, do đó cần có mật khẩu mạnh hơn ở đây. (Không có ích gì khi entropi của mật khẩu đã tăng lên vì sẽ có rất ít người dùng có mật khẩu phức tạp, vì vậy kẻ tấn công có thể chỉ cần thử hầu hết các mật khẩu với độ phức tạp thấp). Lý do đằng sau việc buộc phải sử dụng cùng một mật khẩu cho cả hai tính năng là gì?


3
Có, nhưng nếu tôi sử dụng mật khẩu, tôi sẽ cần sử dụng mật khẩu đó để mở khóa màn hình. Không thuận tiện để nhập 17 ký tự để thực hiện cuộc gọi nhanh. Do đó, hầu hết người dùng sẽ thực hiện nhờ số PIN và đó sẽ là điều đầu tiên kẻ tấn công sẽ thử. Một cách tiếp cận tốt hơn có lẽ là cho phép các cụm mật khẩu để mã hóa đĩa và cho phép số PIN đơn giản trên màn hình khóa. Để tránh các nỗ lực bruteforce trên màn hình khóa, có thể phải khởi động lại lực lượng sau 3 lần thử thất bại dẫn đến yêu cầu mật khẩu.
Christopher Käck

1
Tôi không biết rằng bất kỳ ai khác ngoài Google có thể cho bạn biết lý do, thật không may. Bạn có thể thử trình theo dõi lỗi Android để gửi yêu cầu tính năng, có thể. Điều này có vẻ như một điều hợp lý để nộp ở đó.
eldarerathis

2
Có, chống lại nỗ lực đăng nhập trên màn hình mở khóa, nhưng không chống lại việc giải mã ổ cứng. Đó là những gì tôi đang cố gắng nói, việc mở khóa màn hình không cần phải miễn là mã hóa ổ cứng (cần dài hơn 4 số) và do đó người ta không nên buộc phải sử dụng giống nhau cho cả hai.
Christopher Käck

1
+1, tôi hoàn toàn thuộc về bạn @ ChristopherKäck Quyết định đó thật vô nghĩa, các kỹ sư của Google nên biết rõ hơn, hy vọng họ sẽ khắc phục sớm.
João Portela

1
@Christopher: nhưng bạn đang dựa trên quyết định của mình về tiền đề không chính xác, mã hóa trên đĩa là AES 128 bit, không phải mã PIN gồm 4 chữ số. Xác định xem chương trình này là an toàn hay vốn đã bị lỗi, không phải là chuyên môn của Android.SE.
Lie Ryan

Câu trả lời:


4

Tôi nghĩ rằng tôi đã tìm thấy giải pháp. Kiểm tra liên kết này . Đó là một hack và nó yêu cầu một điện thoại phải được root, nhưng nó cho phép bạn sử dụng mật khẩu chữ và số để mã hóa và mã PIN để mở khóa màn hình.



1

Bằng cách sử dụng mật khẩu / cụm từ so với mã pin bốn chữ số, bạn sẽ tăng tính bảo mật cho thiết bị của mình. Thủ thuật của nó là, ngay cả khi có mật khẩu gồm bốn ký tự, bạn vừa tăng bảo mật vì hai lý do:

  • Bạn đã tăng các ký tự có sẵn.
  • Bạn đã lấy đi kiến ​​thức của những kẻ tấn công về chiều dài pw của bạn.

Nếu kẻ tấn công biết mật khẩu của bạn là 14 ký tự, nó an toàn hơn mật khẩu bốn hoặc tám ký tự, nhưng thống kê điển hình sử dụng phạm vi (1-4, 1-8, 1-14) và không phải là thực tế (mà chỉ đơn giản là tính toán kết hợp có sẵn một chiều dài).

Hiện tại, nó chỉ đơn giản là CÁCH DỄ DÀNG để truy cập dữ liệu điện thoại của bạn. Bà của bạn có khả năng làm như vậy (Không xúc phạm đến bạn hoặc gia đình bạn: P). Vì vậy, trong khi bạn nói đúng rằng có những hạn chế của mã hóa này, phiên bản 'vỡ' làm việc A LOT tốt hơn so với dữ liệu không được mã hóa hiện thực.

Tùy thuộc vào bạn để đánh giá mức độ nhạy cảm và riêng tư của dữ liệu của bạn, cũng như mức độ mục tiêu của bạn đối với dữ liệu đó bị đánh cắp. Chọn một mật khẩu phù hợp là trách nhiệm của bạn một khi bạn đã đánh giá những rủi ro này.


2
Có, nhưng tôi cảm thấy đây là một giải pháp đơn giản cho vấn đề có mật khẩu khác nhau để mở khóa màn hình và giải mã thiết bị (như tôi đã đề cập ở đây android.stackexchange.com/questions/17086/ trộm ) vì chúng được sử dụng khác nhau senario và cần phải có các thuộc tính khác nhau.
Christopher Käck

1

Nếu bạn đang cố gắng bẻ khóa mã hóa ổ đĩa, độc lập với phần còn lại của thiết bị trong trường hợp bạn có thiết bị tắt nguồn hoặc chỉ là chip bộ nhớ, thì đây là một vectơ tấn công khác với sử dụng trên thiết bị bật nguồn thiết bị được bảo vệ bằng mật khẩu nơi khóa giải mã có thể được giữ trong bộ nhớ (dẫn đến các lỗ hổng được sử dụng bởi những thứ như kẻ đánh cắp khóa mã hóa Firewire phổ biến trên PC sử dụng phần mềm mã hóa FDE cũ chứ không phải mô-đun TPM), hoặc màn hình mở khóa có thể bị phá vỡ- bị ép buộc (hoặc có lỗ hổng riêng của nó).

Nếu bạn đang tấn công trực tiếp vào đĩa thì trong trường hợp này bạn không tấn công mã PIN 4 chữ số hoặc mật khẩu người dùng đang mã hóa thiết bị, thứ bạn đang tấn công là khóa AES 128 bit:

Khóa chính là số 128 bit được tạo bằng cách đọc từ / dev / urandom. Nó được mã hóa bằng hàm băm của mật khẩu người dùng được tạo bằng chức năng PBKDF2 từ thư viện SSL. Chân trang cũng chứa một loại muối ngẫu nhiên (cũng được đọc từ / dev / urandom) được sử dụng để thêm entropy vào hàm băm từ PBKDF2 và ngăn chặn các cuộc tấn công bảng cầu vồng vào mật khẩu.

Từ điểm 4 trong phần " Kích hoạt mã hóa trên thiết bị " của Ghi chú về việc triển khai mã hóa trong Android 3.0 mà bạn đã liên kết.

(sẽ là một bình luận nhưng kết thúc quá lâu)


1
Cảm ơn bạn cho nhận xét tốt đẹp này! Một điều mặc dù; Tôi không tìm mật khẩu người dùng (mà rất có thể sẽ là mã pin gồm 4 chữ số, vì bạn buộc phải chia sẻ khóa với mở khóa màn hình và bất cứ điều gì khác sẽ gặp rắc rối khi nhập để gọi điện thoại) để giải mã 128 bit Phím AES? (thay vì tìm kiếm chìa khóa trực tiếp). Nếu tôi băm tất cả 10000 chân bằng hàm PBKDF2 + muối, thì có phải tôi chỉ thử 10000 lần giải mã không?
Christopher Käck

@Melpomene "Tấn công bảng cầu vồng " mà họ nói đến là nơi bạn mã hóa trước tất cả 10.000 kết hợp để xem chúng trông như thế nào được mã hóa và sau đó chỉ cần so sánh những gì trên đĩa với những gì trong bảng cầu vồng của bạn. " Muối ngẫu nhiên " là thứ được sử dụng để giúp ngăn chặn điều này bằng cách tạo ra hơn 10.000 kết hợp mà bạn sẽ phải đoán qua (trừ khi bạn quản lý để xử lý "muối" trước).
GAThrawn

1
Cầu vồng là một cách thông minh để lưu trữ mật khẩu được mã hóa. Và nếu một loại muối được sử dụng, có lẽ nó cần phải được chế tạo đặc biệt chỉ để bẻ khóa mật khẩu với muối đó. Đây không phải là một hoạt động rất khó khăn khi chỉ có 10.000 mật khẩu để lựa chọn. Lưu ý rằng Salt luôn được kẻ tấn công biết đến (vì dường như nó được đọc từ / dev / urandom trong các tài liệu, đây là phần lớn được lưu trữ dưới dạng văn bản rõ ràng hoặc được mã hóa bằng mật khẩu người dùng). Dù bằng cách nào thì mật khẩu người dùng là liên kết yếu.
Christopher Käck

Nhưng tôi thậm chí sẽ không cần phải xây dựng một cầu vồng kể từ khi lưu trữ (hoặc tính toán) 10.000 băm không quá khó đối với bộ nhớ (bộ xử lý) của tôi.
Christopher Käck

Sử dụng chức năng phái sinh chính như PBKDF2 có vẻ như là một tin tốt, nhưng pin 4 chữ số thông thường vẫn chỉ có 10000 kết hợp có thể.
João Portela


0

Nếu bạn đã bật tính năng xóa từ xa (giả sử thiết bị vẫn hoạt động với thiết bị được mã hóa), mã PIN có thể không bảo mật thiết bị của bạn mãi mãi, nhưng nó có thể đủ lâu để cho bạn thời gian để xóa thiết bị.


2
Vấn đề là mã PIN ngắn chỉ có thể bảo mật thiết bị khi bật. Do đó, tắt thiết bị bị đánh cắp sẽ ngăn không cho thiết bị bị xóa và ngoài ra, mã PIN có thể bị phá vỡ trong một cuộc tấn công vũ phu ngoại tuyến. Do đó, một mã PIN ngắn không giúp bạn trong tình huống này.
Robert

@Robert, tôi không quá quen thuộc với cách hoạt động của lau từ xa. Nếu nó được thực hiện thông qua Exchange, điện thoại có phải ở cùng thời điểm lệnh xóa từ xa được ban hành không? Tôi nghĩ rằng nếu tôi có thể phát hành một điều khiển từ xa trong vòng 30 phút hoặc mất điện thoại thì đủ tốt cho tôi, nhưng tôi không có bất kỳ dữ liệu tài chính nào, mối quan tâm chính của tôi là email công việc GMail của tôi.
Cơ hội

2
Điện thoại phải được bật và trực tuyến một thời gian sau khi bạn đã ban hành lệnh xóa từ xa. Nếu điện thoại đã bị tắt (và tắt), lệnh lau là vô ích.
Robert
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.