3

我可以将某些文件解密到内存中，然后在不使用硬盘的情况下将其用作常规文件吗？

更准确地说，我想用一些敏感数据解密一个 .mdb 文件，并像从磁盘加载一样对其进行操作，但不使用临时文件。我想也许我可以从解密的字节数组中做一个文件对象或流（仍然必须计算代码），但是，问题是 OleDbConnection 从包含文件名的字符串加载数据。

让我们试着举个例子：

byte[] someArrayWithTheContentsOfAdotMDBFile = getDecryptedFile();

[...]

// 即使我将数组包装到文件或流中，加载过程也需要文件名

using (OleDbConnection connection = new OleDbConnection(@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=.\"+ fileNameHere)) // can fileNameHere  be a File object, stream or any trick like that??

编辑：由于答案采用这种方式，我将标题更改为“正在加载数据库......”。我仍然有兴趣从内存中加载任何文件类型，但让我们把它留给另一个线程

4

4 回答 4

3

我不认为访问可以做到这一点......

但是您使用以下设置来实现您的目标：

  • 使用 SQLite
    它可以使用内存（纯 RAM）作为存储并对其进行操作

  • 使用加密的“SQLite-Dump”（即备份）作为您的传输机制（文件）
    当您需要对其进行操作时，将其加载到内存中，解密它，创建一个空的“SQLite in-memory instance”并“恢复”它从您的解密流中

注意：
您要求的方案可以使用 SQLite 等一些数据库引擎，但因为您需要解密文件，您的应用程序必须包含解密所需的密钥。
这意味着如果有人想读取您的数据库文件，他们可以通过首先分析您的应用程序，恢复解密密钥等。
如果您使用“对称加密”（例如 AES），那么他们甚至可以在您的应用程序没有注意到的情况下修改数据库文件.
如果您使用“非对称加密”（例如 RSA），那么他们仍然可以读取它，但他们无法修改数据库文件。

关于安全性的一个非常重要的一点是：在您无法 100% 控制的机器上运行的任何东西都可能被“破解”——这仅取决于攻击者的能力和动机。

于 2012-12-15T00:22:52.950 回答
2

Have you considered using SQL Server Compact with database encryption?

SQL Server Compact is a file-based database, not server-based, which as you said in a comment is preferable for you.

The file on disk is encrypted. It is decrypted in memory, decrypted data is not stored to disk.

It's extremely simple to work with - you just need to put the password in the connection string when you open a connection to the database.

Seems this would fit your use case.

An aside on Password/Key management: Yeah, thanks Alexei, I was hoping nobody would mention that one. :-) It's a tough problem, especially if we're talking about an application that is distributed to the people who you want to protect the database from.

Ultimately, it can't be done. If your application can open the database, and you distribute your application, an attacker can reverse-engineer your application and figure out how to open the database. .NET apps are of course particularly easy to decompile.

The way I see it, you can either just put the key in the code, and accept that anyone who decompiles the code will find it; or you can try to make efforts to obfuscate it (break up the key into various places in the code, write ugly complicated code to reconstruct it, etc.) If you do that, it will still be breakable - you'll just raise the bar from "anyone who decompiles the code" to "anyone who decompiles the code and is willing to spend the time & effort working through your obfuscation".

于 2012-12-15T00:11:15.513 回答
1

如果某些内容需要文件名，则您无法绕过公开可见的文件（无论是磁盘上的普通文件、ram 磁盘还是任何其他类型的设备）。

你可以试试：

  • 在文件上配置安全性，以便只有当前用户可以打开它
  • 考虑使用 delete-on-close 标志创建临时文件，这样它就不会停留足够长的时间
  • 找到另一个可以从内存存储中工作的数据库引擎。

旁注：您需要仔细考虑为什么要走这条路。事实证明，您尝试创建的限制要么无法解决您的问题，要么考虑到您的用户完全矫枉过正。

于 2012-12-15T00:00:32.590 回答