2012-10-22 28 views
7

Tôi có câu hỏi liên quan đến C#.Tháo C#

Tôi hiện đang làm việc trên một sản phẩm phần mềm y tế và một trong những điều quan trọng là đảm bảo rằng dữ liệu của bệnh nhân được mã hóa. Tôi có hai câu hỏi liên quan đến điều này:

1.) Bảo mật của Microsoft .NET thực hiện AES (Rijndael) từ System.Security.Cryptography như thế nào? Liệu nó có bất kỳ lỗi bảo mật được biết đến, hoặc tôi tốt chỉ bằng cách sử dụng thực hiện MS? (lưu ý, tôi biết nền tảng cơ bản về cách các thuật toán này hoạt động, nhưng tôi không thực sự sâu vào nó để có được một ý tưởng về cách thức hoạt động của nó).

2.) Vì dữ liệu được lưu trữ trên cùng một máy tính như ứng dụng, làm cách nào để nhận thông tin từ ứng dụng C#? Giả sử tôi đã ở đâu đó trong các mã

string encrypPassword = "ThisIsMyPassword"; 
string encryptedString = EncryptString(ClearString, encrypPassword); 
// save encryptedString to harddrive 

Tôi biết rằng kẻ tấn công chỉ có thể đi xuống mã lắp ráp, và tại thời điểm đó không có gì là tất cả những gì có thể làm chống lại điều này (hệ thống có để có thể mã hóa/giải mã dữ liệu), nhưng có giống như một phím tắt cho C# để lấy encrypPassword, vì nó được quản lý hay không, điều gì đó vẫn yêu cầu bạn đi xuống mã lắp ráp?

+0

bản sao có thể có của [Cách lưu trữ khóa mã hóa một cách an toàn trong một hội đồng .NET] (http://stackoverflow.com/questions/2528405/how-to-safely-store-encryption-key-in-a-net- lắp ráp) – Rawling

+5

Điểm 2) là vấn đề chính của bạn, đừng lo lắng về 1). –

+1

Bạn có thể xem DPAPI, xem ví dụ: http://stackoverflow.com/q/5620028/60761 –

Trả lời

5

Nếu bạn có mật khẩu cố định được biên dịch vào ứng dụng, bạn không cần phải quan tâm đến bảo mật của AES và lỗi bảo mật đã biết vì dữ liệu của bạn không an toàn. Một người hiểu biết đầy đủ với quyền truy cập vào PC sẽ có thể giải mã tất cả dữ liệu.

Và định vị mật khẩu cố định thường không yêu cầu bất kỳ kiến ​​thức lập trình nào. Một trình soạn thảo hex tốt sẽ làm trong hầu hết các trường hợp. Bạn thậm chí không cần biết ngôn ngữ lập trình nào được sử dụng.

Nếu dữ liệu của bạn được sử dụng bởi một người dùng, thì bạn có thể buộc mật khẩu cho dữ liệu bệnh nhân vào mật khẩu Windows (hoặc tài khoản) của họ. Windows cung cấp một số chức năng cụ thể cho điều đó. Xem http://msdn.microsoft.com/en-us/library/aa302402.aspx để biết cách truy cập nó từ .NET.

+0

Nếu bạn muốn tự mình thử, hãy sử dụng ILDASM hoặc bộ phản xạ (cả hai đều miễn phí) để tìm khóa của bạn. Bạn sẽ tìm thấy nó là tầm thường để có được nó ra khỏi nhị phân. –

0

Để lưu trữ dữ liệu mật khẩu của bạn, bạn có thể sử dụng lớp SecureString từ không gian tên System.Security.

+1

'SecureString' có một số ưu điểm, nhưng nó hiếm khi có liên quan. OP có nhiều vấn đề lớn hơn, rằng 'SecureString' không thể giải quyết được. – CodesInChaos

+1

@Jodrell Nó thậm chí không ngăn chuỗi bị đọc. Nó chỉ bảo vệ chống lại một số mối đe dọa cụ thể, chẳng hạn như lỗi-dumps và các tập tin trao đổi. – CodesInChaos

0

Hầu hết các obfuscators phong nha sẽ mã hóa các chuỗi từ mã của bạn trước khi lưu trữ chúng trong phần dây của hội đồng, và tiêm một phương pháp để giải mã chúng trước khi sử dụng. Những kỹ thuật này cũng đã từ lâu được thiết kế ngược bởi disassemblers.

Thực tế, hầu như không có cách nào để lưu trữ chuỗi một cách an toàn bằng bất kỳ ngôn ngữ lập trình nào. Một người nào đó có thể khá nhiều hoặc là tìm chuỗi, hoặc đảo ngược kỹ sư logic của bạn được sử dụng để xây dựng nó. Điều tốt nhất bạn có thể làm là xếp hàng kẻ tấn công đủ lâu để làm cho nó không xứng đáng với thời gian và công sức của họ.

Trong trường hợp của bạn, tôi có thể lưu trữ mật khẩu được mã hóa trong ứng dụng (như, tự mã hóa nó theo cách thủ công bên ngoài ứng dụng của bạn và sao chép/dán nó vào). Có thể chia nó thành nhiều phần để nó không được lưu trữ như một chuỗi đơn lẻ. Sau đó đặt nó trở lại với nhau và unencrypt nó tại thời gian chạy, sau đó tại thời gian chạy lưu nó trong một SecureString. Ngoài ra đầu tư vào một obfuscator tốt, vì nó sẽ giúp che giấu logic không mã hóa của bạn (mà sẽ trở thành liên kết yếu trong an ninh).

1

Để trả lời phần đầu tiên của câu hỏi ban đầu của bạn - việc triển khai Windows gốc của AES được NIST chứng nhận là tuân thủ FIPS 140-2.Truy cập đến việc thực hiện chứng nhận được giới hạn:

  1. Sử dụng API của Windows Crypto

  2. Sử dụng wrapper CAPICOM com để Windows API Crypto

  3. Sử dụng lớp Net AesCryptoServiceProvider trong hệ thống Không gian tên .Security.Cryptography (lớp này không có sẵn cho đến khi .Net Framework 3.5)

Điều đó được nói, việc thực hiện trong lớp RijndaelManaged là như nhau, nó chỉ không được thông qua quá trình chứng nhận NIST (quá trình này là rất dài và rất tốn kém).

Thuật toán Aes rất an toàn (mã hóa cấp quân sự - đặc biệt là biến thể khóa 256 bit).

Mối quan tâm lớn nhất (đồng ý với các áp phích ở trên) là giữ mật khẩu mã hóa của bạn được nhúng trong ứng dụng ở dạng văn bản thuần túy.

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