Điểm:0

Làm cách nào để đảm bảo các tệp trên máy khách không bị giả mạo bởi khách hàng?

lá cờ ro

Tôi đang thiết kế một chương trình mà khách hàng có thể tải xuống máy tính. Chương trình này cần thường xuyên đồng bộ hóa với máy chủ trực tuyến của tôi để xác nhận rằng Mã kích hoạt của khách hàng chưa hết hạn và họ đang thanh toán hóa đơn. Tuy nhiên, tôi muốn chương trình có thể chạy trong khoảng thời gian tối đa là 5 ngày mà không cần phải kết nối. Điều này sẽ cho phép khách hàng sử dụng chương trình trong một thời gian nếu họ mất kết nối internet. Đây sẽ là một phần thưởng lớn so với các chương trình khác mà khách hàng của tôi sử dụng trở nên hoàn toàn vô dụng nếu không có internet.

Để đạt được điều này, tôi muốn lưu trữ dấu thời gian trong tệp văn bản cục bộ.Mỗi khi chương trình chạy, nó có thể kiểm tra dấu thời gian để xem có cần đồng bộ hóa trực tuyến hay không. Vì vậy, nếu 5 ngày trôi qua mà không có đồng bộ hóa trực tuyến, chương trình sẽ từ chối bắt đầu cho đến khi máy khách đồng bộ hóa lại.

Vấn đề là làm cách nào để tôi lưu trữ tệp này một cách an toàn để khách hàng không thể giả mạo nó. Nếu khách hàng chỉ có thể mở tệp văn bản và thay đổi dấu thời gian, thì chương trình có thể bị lừa khi nghĩ rằng nó không bao giờ phải đồng bộ hóa.

Tôi đã xem xét những điều sau đây:

  1. Lưu trữ khóa đối xứng bên trong chương trình được sử dụng để mã hóa tệp văn bản, sau đó giải mã nó khi cần để đảm bảo tính xác thực của nó. Vấn đề ở đây là khóa đối xứng sẽ phải được cố định và lưu trữ trong chương trình. Tôi là một lập trình viên mới hơn về Java nhưng theo những gì tôi hiểu thì các chương trình có thể được biên dịch ngược lại và thu được khóa đối xứng. Ngoài ra, khóa đối xứng này có thể nằm trong bộ nhớ và được lấy. Tất cả các bản phân phối của chương trình sẽ phải có cùng một khóa đối xứng được tích hợp sẵn (tôi cho là vậy), và đây sẽ là một vấn đề phải không?

  2. Một số cách ký vào tệp để đảm bảo tính xác thực. Tôi không biết nhiều về mã hóa nhưng điều này nghe giống hệt #1.

  3. Mã hóa bất đối xứng. Nhưng tôi không chắc làm thế nào điều đó có thể đạt được ở đây. Khi chương trình đồng bộ hóa, máy chủ trực tuyến có thể mã hóa dấu thời gian bằng khóa chung và gửi lại cho chương trình để lưu trữ nội dung được mã hóa trong một tệp. Sau đó, nó có thể được giải mã bằng khóa riêng. Điều này sẽ đảm bảo dấu thời gian được tạo bởi máy chủ của tôi chứ không phải máy khách. Vấn đề là bất kỳ ai cũng có thể mã hóa dấu thời gian bằng khóa chung và đặt nó vào tệp, vì khóa chung là công khai. Ngoài ra, khóa riêng sẽ phải được lưu trữ trong chương trình, điều này quay lại vấn đề tương tự như # 1.

Thậm chí có thể đạt được những gì tôi đang cố gắng đạt được không?

Điểm:0
lá cờ my

Vấn đề là làm cách nào để tôi lưu trữ tệp này một cách an toàn để khách hàng không thể giả mạo nó. Nếu khách hàng chỉ có thể mở tệp văn bản và thay đổi dấu thời gian, thì chương trình có thể bị lừa khi nghĩ rằng nó không bao giờ phải đồng bộ hóa.

Tôi đã xem xét những điều sau đây:

  1. Một số cách ký vào tệp để đảm bảo tính xác thực.

Đó sẽ là gần nhất; cách rõ ràng sẽ là nếu máy chủ có khóa chữ ký riêng và chương trình có khóa chung tương ứng. Sau đó, khi bạn được kết nối, máy chủ có thể ký dấu thời gian hiện tại và gửi dấu thời gian và chữ ký đó cho khách hàng.

Sau đó, khi máy khách không thể kết nối, thì anh ấy sẽ kiểm tra dấu thời gian/chữ ký gần đây hơn đã được tải xuống và xác minh chữ ký đó (sử dụng khóa chung được cài đặt với máy khách); nếu điều đó hợp lệ, thì bạn kiểm tra xem dấu thời gian có cách đây không quá năm ngày hay không.

Ngoài ra, bạn có thể bao gồm hàm băm của một số tệp có liên quan (những tệp mà máy khách không nên sửa đổi) cùng với những gì máy chủ ký; tại thời điểm xác minh, khách hàng sẽ băm các bản sao của tệp và đưa tệp đó vào quá trình xác minh.

Kẻ tấn công không thể sửa đổi dấu thời gian, bởi vì anh ta không thể sửa đổi chữ ký (và xác minh nó); anh ta có thể thay thế dấu thời gian/chữ ký bằng dấu thời gian trước đó, tuy nhiên điều đó sẽ không đạt được gì.

Các cách có thể để tấn công này:

  • Sửa đổi 'thời gian hiện tại'; hầu hết các hệ điều hành đều cho phép bạn đặt thời gian theo ý muốn của người dùng. Điều này giả định một dấu thời gian đã được xác thực (nếu không đặc biệt chính xác).

  • Sửa đổi chương trình (để sửa đổi khóa chung hoặc nhiều khả năng hơn là thay thế logic xác thực bằng thứ gì đó luôn nói 'nó hợp lệ). Đó luôn là một vấn đề khi bạn đang chạy trong một cơ sở tính toán không đáng tin cậy.

lá cờ ro
Xin chào @poncho, cảm ơn vì tất cả những ý tưởng tuyệt vời. Tôi sẽ dành một chút thời gian để tiêu hóa điều này và lấy lại cho bạn. ân sủng
lá cờ ro
Tôi đánh giá cao sự giúp đỡ của bạn. Tôi nghĩ rằng tôi hiểu những gì bạn đang nói. Mã hóa RSA bất đối xứng có thể được sử dụng ngược lại, trong đó khóa riêng tư ký một cái gì đó và sau đó khóa chung có thể được sử dụng để xác nhận tính xác thực. Lưu trữ phiên bản đã ký và thư gốc, sau đó đảm bảo chúng khớp nhau. Chữ ký chỉ có thể là từ khóa riêng. Có ý nghĩa. Theo như tấn công nó, Có thể sửa đổi mã trong chương trình đã biên dịch không? Tôi không biết nhiều về điều đó.Về cơ bản, bất kỳ chương trình nào cũng có thể được sửa đổi và đó chỉ là thứ mà các nhà phát triển phải chung sống?
poncho avatar
lá cờ my
@Geoff: "Khi tấn công nó, Có thể sửa đổi mã trong chương trình đã biên dịch không?"; nó không tầm thường, nhưng nó có thể được thực hiện bởi một người có một chút kinh nghiệm và công cụ phù hợp.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.