CODEWITHSUNDEEP
c#databasefilememory
Cristo
Cristo

Reputation: 710

loading database file from memory

Can I decrypt some file into memory and then use it as a regular file without using harddisk?

More exactly, I want to decrypt a .mdb file with some sensitive data and operate with it like loaded from disk but without using temporary files. I figured that maybe i could do a File object or stream (still have to figure the code) from the decrypted byte array, but then, a problem is that the OleDbConnection loads data from a string containing file name.

Lets try to example this:

byte[] someArrayWithTheContentsOfAdotMDBFile = getDecryptedFile();

[...]

// Even if I get to wrap the array into a File or Stream, the load process requires a filename

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??

edit: As the answers took the thread that way, I changed title to "loading database...". I'm still interested in loading any file type from memory, but lets leave that for another thread

Upvotes: 3

Views: 2253

Answers (4)

Carson63000
Carson63000

Reputation: 4232

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".

Upvotes: 2

Jay
Jay

Reputation: 3355

Memory Mapped Files seem to be the answer here :)

http://blogs.msdn.com/b/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx

Also

http://www.codeproject.com/Articles/138290/Programming-Memory-Mapped-Files-with-the-NET-Frame

Upvotes: 0

Yahia
Yahia

Reputation: 70369

I don't think that access can do that...

BUT you use the following setup to achieve your goal:

  • Use SQLite
    It can use in-memory (pure RAM) as storage and oprate on that

  • Use an encrypted "SQLite-Dump" (i.e. Backup) as your transport mechanism (file)
    When you need to operate on it, load it into memory, decrypt it, create an empty "SQLite in-memory instance" and "restore" it from your decrypted stream

BEWARE:
The scheme you ask for is possible with some DB engines like SQLite BUT since you need to decrypt the file your application must contain the key needed for decryption.
This means that if someone wants to read your DB file they can by first analyzing your application, recovering the decryption key etc.
IF you use "symmetric encryption" (for example AES) then they can even modify the DB file without your application noticing that.
IF you use "asymmetric encryption" (for example RSA) then they can still read it but they can't modify the DB file.

One very important point regarding security: ANYTHING that runs on a machine that is not 100% under your control can be "cracked" - it only depends on how capable and how motivated the attacker really is.

Upvotes: 3

Alexei Levenkov
Alexei Levenkov

Reputation: 100527

If something requires file name you can't get around having publicly visible file (whether normal file on disk, ram disk or any other kind of device).

You can try:

  • configure security on the file so only current user can open it
  • consider creating temporary file with delete-on-close flag so it does not stay around long enough
  • find another DB engine that can work from in-memory storage.

Side note: you need to think carefully why you are trying to go this route. It may turned out that restrictions you are trying to create either not solving your problem OR complete overkill considering your users.

Upvotes: 1

Related Questions