2012-09-27 38 views
9

Ứng dụng của tôi cần mã hóa một số dữ liệu (mã thông báo phiên của người dùng). Hầu hết các ví dụ tôi thấy xung quanh có một phương pháp mà tạo ra một khóa sử dụng một cụm từ mật khẩu và muối, như:Chúng tôi lưu trữ khóa/cụm mật khẩu/muối để mã hóa ở đâu?

public static Key generateKey(char[] passphrase, byte[] salt) { 
    ... 
} 

hiểu biết của tôi là chúng ta có ba tùy chọn để tạo ra các cụm từ mật khẩu:

  1. Có người dùng nhập nó mỗi khi ứng dụng bắt đầu (gây phiền toái cho người dùng).
  2. Viết mã cụm mật khẩu vào chính ứng dụng. Thuận tiện hơn cho người dùng, nhưng ai đó có thể tìm ra cụm từ mật khẩu của bạn được cung cấp cho ứng dụng nhị phân của bạn.
  3. Tạo ngẫu nhiên cụm mật khẩu, nhưng sau đó chúng tôi phải lưu trữ Khóa được tạo trên đĩa. Bây giờ chúng tôi vừa chuyển vấn đề để lưu trữ khóa an toàn trên đĩa, điều này dường như không thể. Nếu kẻ tấn công tìm thấy khóa được tạo ra, vấn đề lớn.

Tùy chọn # 1 sẽ không hoạt động đối với tôi. Các tùy chọn # 2 và # 3 dường như không hoàn thiện, trừ khi tôi hiểu lầm về cách làm thế nào để thực hiện điều này (hy vọng rằng tôi). Cách được khuyến nghị để làm điều này là gì nếu chúng ta không thể đi với # 1? Chúng ta có đặt một loạt các vòng hãm hiếp để kẻ tấn công nhảy qua và hy vọng điều tốt nhất không?

Cảm ơn

Trả lời

2

"Chúng ta đưa vào một loạt các hoops obfuscated cho kẻ tấn công để nhảy qua và hy vọng cho là tốt nhất?" Về cơ bản có. Kích thước và số lượng vòng lặp là mức độ khó mà bạn muốn tạo ra.

Nếu bạn không sử dụng máy chủ, thì bất cứ điều gì bạn làm để theo dõi và mã hóa dữ liệu đều có thể đảo ngược. Tuy nhiên, bạn có thể làm cho nó thực sự khó khăn. Ví dụ: một kỹ thuật tôi đã sử dụng để bảo vệ một số nội dung video.

  1. Thay thế 1024 byte đầu tiên của tiêu đề (MP4) với 1024 byte được lấy từ giữa một trong các tài sản hình ảnh ứng dụng. Tôi đã thử một số sửa chữa, tất cả đều thất bại trong việc khôi phục tập tin tự động - mặc dù nó có thể được thực hiện thủ công. Sau đó ...

  2. Đã mã hóa tệp bằng khóa cá nhân được 256 byte lấy từ nội dung hình ảnh khác.

  3. Khi khóa được trích xuất, nó được băm thông qua một thuật toán thực hiện tất cả các loại toán học không nhạy cảm khác để mang chìa khóa.

  4. Đã sử dụng trình theo dõi biên dịch trước.

Tôi đã cố gắng đảo ngược kỹ sư này, thậm chí biết cách thực hiện và khó thực hiện nỗ lực không đáng giá.

Có nhiều cuộc thảo luận về SO tóm tắt như; Nếu bạn chỉ đơn giản là muốn dừng sao chép, làm cho nó khó khăn (chi phí so với phần thưởng) nhưng nếu không ngủ dễ dàng bởi vì cuối cùng không có gì bạn có thể làm. Nếu dữ liệu nhạy cảm về mặt thương mại, thì máy chủ được kết hợp với bảo mật cấp hệ thống (ví dụ: mã hóa toàn bộ thiết bị và không có gốc) là bắt buộc.

0

Bạn lưu trữ muối cùng với dữ liệu được mã hóa, nó không phải là thông tin bí mật. Bạn có thể lấy được khóa trên một trong hai thứ mà người dùng nhập vào hoặc một số loại thuộc tính thiết bị: (băm) IMEI, địa chỉ MAC, v.v.

Về cơ bản, hãy nghĩ bạn là ai bảo vệ dữ liệu của mình và tại sao. Vì người dùng cần điều này, không có nhiều điểm cố gắng để bảo vệ nó khỏi họ. Nếu bạn lưu trữ tệp này trong một tệp riêng tư, các ứng dụng khác không thể đọc nó trên điện thoại không bắt nguồn từ. Nếu bạn muốn bảo vệ nó trên điện thoại bắt nguồn, mã hóa có thể hữu ích, nhưng miễn là khóa nằm trong ứng dụng, hoặc có nguồn gốc dựa trên thứ gì đó trên thiết bị, nó chỉ làm cho khó hơn, không thể phục hồi.

Android không có dịch vụ kho khóa toàn hệ thống, nhưng không có API công khai và có thể thay đổi. Bạn có thể sử dụng nó để bảo vệ (các) khóa của mình, nếu bạn sẵn sàng chấp nhận rủi ro phá vỡ ứng dụng của bạn trên các phiên bản trong tương lai. Một số chi tiết tại đây: http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html

Các vấn đề liên quan