6

Toàn bộ vấn đề là thiết kế một hệ thống đơn giản, nơi người dùng có thể gửi tin nhắn được mã hóa giữa chúng (với sự hỗ trợ từ máy chủ).Mật mã khóa công khai với mật khẩu do người dùng chọn?

Trong trường hợp này, khách hàng không có bộ nhớ cục bộ, vì vậy tôi buộc phải sử dụng mật khẩu mà người dùng có thể chọn, ghi nhớ và nhập khi cần. (Tôi biết điều này làm suy yếu toàn bộ hệ thống nhưng đây là một yêu cầu khó khăn)

yêu cầu khác là máy chủ không thể lưu trữ các khóa riêng cleartext hoặc bất kỳ dữ liệu khác có thể được sử dụng để giải mã thông điệp (ví dụ: chỉ người dùng có thể đọc tin nhắn được mã hóa, quản trị viên máy chủ sẽ không thể).

Cách tiếp cận của tôi là tạo cặp khóa bất đối xứng trên máy khách, xuất bản khóa công khai trên máy chủ cùng với bản sao mã hóa khóa cá nhân (được mã hóa bằng mật khẩu người dùng). Sau đó, người dùng có thể gửi tin nhắn được mã hóa tới người dùng khác, sử dụng khóa công khai của người nhận đã được xuất bản; khi người dùng cần giải mã thư, khóa cá nhân (được mã hóa) của anh ta được tìm nạp trên máy khách từ máy chủ, được giải mã bằng mật khẩu do người dùng cung cấp và sau đó được sử dụng để giải mã thư.

Điều này có ý nghĩa gì không? Có lỗ hổng nào trong thiết kế hệ thống này không? (ngoài điểm yếu bắt nguồn từ người dùng lựa chọn mật khẩu ngắn hoặc xấu) Cách tiếp cận này đã được sử dụng trong các tình huống tương tự chưa?

Cảm ơn bạn :)

+0

Như được mô tả, nó có vẻ giống với những gì hushmail.com thực hiện. Họ có các trang trắng trên trang web của họ mô tả bảo mật. –

+0

Cảm ơn tôi sẽ xem qua chúng. – Patonza

Trả lời

2

Nếu tôi hiểu chính xác, bạn muốn tạo hệ thống trong đó hai người dùng có thể bắt đầu giao tiếp riêng tư thông qua máy chủ mà họ không tin tưởng.

Điều này sẽ không hoạt động.

Trong trường hợp bạn đặt ra, máy chủ có thể tạo cặp khóa riêng của nó và xuất bản khóa công khai của nó thay cho người dùng. Khi người dùng mã hóa một tin nhắn, dự định nó cho đối tác của họ, họ không thể phát hiện ra rằng máy chủ đã thay thế khóa công khai của nó.Máy chủ giải mã thông báo, trình bày nó cho các quản trị viên máy chủ, và mã hóa lại nó (hoặc một số thông báo mới mà họ đã tạo) với khóa công khai đối tác thực sự và chuyển nó đến đích.

Điều bị thiếu ở đây là cơ quan cấp chứng chỉ. Đây là một bên thứ ba đáng tin cậy có chữ ký số ràng buộc giữa khóa công khai và tên người dùng. Ràng buộc này được gọi là chứng chỉ. Bằng cách này, khi máy chủ trình bày khóa công khai cho một máy khách để sử dụng để mã hóa, máy khách có thể sử dụng khóa công khai của CA để xác minh chứng chỉ và đảm bảo rằng khóa công khai mà họ sắp mã hóa thuộc về người nhận dự định, và không phải là kẻ tấn công.

Người dùng phải tin cậy CA, điều này có thể ngon miệng hơn là tin tưởng vào quản trị viên máy chủ. Tuy nhiên, cũng phải có cách giả mạo để lưu trữ chứng chỉ CA. Trong thực tế, điều này thường được thực hiện bằng cách sử dụng MAC dựa trên mật khẩu (mã xác thực thông báo). Hoặc, CA có thể được ký điện tử bằng khóa riêng của người dùng (không bao giờ thấy điều này được thực hiện, nhưng nó sẽ hoạt động). Nhưng phần khôn lanh sẽ nhận được chứng chỉ CA từ một nguồn đáng tin cậy, bỏ qua máy chủ không đáng tin cậy.

Theo như mã hóa khóa cá nhân bằng mật khẩu, điều đó được thực hiện rất thường xuyên và an toàn như mật khẩu bạn chọn.

Ngoài ra, nếu người dùng có thể chia sẻ bí mật với nhau ngoài băng, bạn không cần mã hóa khóa công khai. Máy khách có thể mã hóa bí mật được chia sẻ với mật khẩu do người dùng chọn và lưu trữ văn bản mã hóa trên máy chủ.

+0

Có, có vẻ như nó sẽ không hoạt động. Đoán tôi sẽ phải tìm một cách để sử dụng một CA đáng tin cậy :) Cảm ơn bạn đã tư vấn. Dù sao, chỉ cần biết, giả sử máy chủ không bị giả mạo, kẻ tấn công chỉ có thể truy cập * đọc * vào máy chủ sẽ không thể chặn bất cứ điều gì, phải không? Ngoài ra, nếu tin cậy được chỉ định một lần với một hệ thống khác (ví dụ: sử dụng ứng dụng khách có thể xác minh đối với CA đáng tin cậy) và sau đó được lưu trữ, mã hóa, trên máy chủ, thì nó sẽ hoạt động, phải không? – Patonza

+0

@Patonza - Có, nếu ủy thác được thiết lập ban đầu với một CA đáng tin cậy, khách hàng có thể lưu trữ khóa công khai của đối tác trên máy chủ * xác thực * nó (không * mã hóa *) bằng mật khẩu của riêng họ. Bởi vì dữ liệu được lưu trữ được bảo vệ bằng MAC, máy chủ không thể giả mạo nó. – erickson

+0

Nếu một cuộc tấn công chỉ có quyền truy cập đọc trên máy chủ, anh ta không thể thay đổi các thông điệp đi qua nó, nếu đó là ý của bạn. Nhưng cuộc tấn công tôi mô tả là nơi mà chính máy chủ bị hỏng. – erickson

1

Như được mô tả, lược đồ có vẻ hợp lý ở chỗ nó nên cho phép người khác gửi tin nhắn cho người khác mà người nhận có thể đọc. Có một số vật phẩm đến với tâm trí mà bạn có thể đã nghĩ về nhưng bỏ qua cho ngắn gọn:

  • Khi mã hóa khóa bí mật, sử dụng giống như PBKDF2 với muối và một số số lượng khá lớn nó lặp đi lặp lại.
  • Điều này có thể ngụ ý, nhưng thay vì mã hóa bằng khóa công khai, có thể tạo ra một khóa ngẫu nhiên (ví dụ: 32 byte dữ liệu ngẫu nhiên nếu sử dụng, ví dụ: AES-256). Mã hóa tin nhắn bằng khóa đó, mã hóa khóa bằng khóa công cộng và gửi cả hai phần.
  • Như được mô tả, không có nhận dạng người gửi. Nó cho phép gửi tin nhắn hoàn toàn ẩn danh. Điều này có thể được dự định, nhưng nếu không, thì một số loại nhận dạng/xác thực sẽ là cần thiết.
  • Hơi giống với mục nhập trước đó, không có xác thực thông báo nào được mô tả. Kẻ tấn công có thể thay đổi tin nhắn được mã hóa và người nhận sẽ không thể nói rằng nó đã bị thay đổi. Mặc dù, nếu nó là một tin nhắn văn bản, nó sẽ được khá rõ ràng rằng nó đã được sửa đổi, bởi vì nó sẽ chỉ là văn bản bị cắt xén. Tuy nhiên, có một số loại dữ liệu có thể không dễ dàng biết được liệu nó đã được sửa đổi chưa.
+0

Cảm ơn bạn, quan điểm của bạn về xác thực người gửi/xác thực thư, trong khi không phải ưu tiên của tôi trong thiết kế cụ thể này, rất thú vị: có thể thông điệp có thể được ký bằng một cặp khóa khác và khách hàng có thể lưu trữ thư mục được mã hóa của người gửi biết/đáng tin cậy trên máy chủ - Tôi sẽ xem xét điều này. Và tôi sẽ làm theo lời khuyên của bạn về PBKDF2, mà dường như là tiêu chuẩn của ngành để tăng cường trọng điểm. :) – Patonza

+0

@Patonza - Không có xác thực, bạn không thể có quyền riêng tư. Bảo mật có nghĩa là giữ bí mật từ "ai đó". Nếu bạn không biết bạn đang nói chuyện với ai, làm sao bạn biết đó không phải là "ai đó"? – erickson

+1

P.S. Trong khi tôi cho rằng câu trả lời này sai (ngụ ý rằng hệ thống được đề xuất sẽ chỉ cho phép người nhận định giải mã thư), lời khuyên trong mỗi điểm bullet là cực kỳ tốt và cần được xem xét cẩn thận nếu thực hiện một hệ thống thực. – erickson

1

Điều này nghe có vẻ giống như những gì hushmail đã làm. Tuy nhiên, có một vấn đề lớn trong đó, vì họ có khóa riêng của người dùng (được mã hóa), họ chỉ cần đẩy xuống một applet bị hack có thể truyền mật khẩu của người dùng đến máy chủ (mà họ đã làm).

Một giải pháp tốt hơn là tránh sử dụng khóa riêng tư đó trên máy chủ. Với yêu cầu không có bộ nhớ cục bộ, điều đó đã hết.

Tại sao không sử dụng mã hóa đối xứng thông qua mật khẩu được chia sẻ trước? Nó có thể được thực hiện mà không cần lưu trữ ở phía khách hàng. Tôi tin rằng đây là những gì @erickson đã nói trong đoạn cuối của mình.

+0

Tôi không giả định mã máy khách phải được tải xuống từ máy chủ. Nó có thể được lưu trữ chỉ đọc trên máy khách. Mã hóa đối xứng không phải là lựa chọn ở đây, bởi vì người dùng sẽ phải "gặp" trước khi họ có thể chia sẻ dữ liệu. Cảm ơn lời khuyên nào :) – Patonza

1

Vấn đề chính là nếu mã giải mã được tải xuống từ máy chủ, một (hoặc quản trị viên máy chủ hoặc tin tặc đã truy cập vào máy chủ) có thể thay thế mã này. Người dùng ở phía máy khách nên tin cậy máy chủ, nhưng anh ta không có cách nào để xác minh máy chủ để tin tưởng nó.

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