System.Data.SQLite

Hello again :)

Since i need to encrypt my database i was looking for some info about the encryption strength of SQLite, but i can't find much information regarding which algorithm is used, the key strength etc.
Since on sqlite.org i can't find any forum i try to ask my question here.

Since the author of SQLite offers some kind of encryption addon for SQLite i'm wondering if the built in encryption routine is nothing more than a "placeholder" for better encryption algorithms.
I would wish something like AES as encryption routine but somewhere i red SQLite uses RC4 encryption or something like that. I never heard about RC4 and the few other things i discovered told me just bad things about RC4.
Could somebody here be so kind and enlight me? Is RC4 the actual encryption? Is it strong enough for corporate use?

Thank you

When it comes to files stored on the local computer, there are always a means to hack them even with encryption.  Since the source code of the provider is available, all you'd have to do is recompile it yourself and redirect all the calls to somewhere else.

The SQLite ADO.NET provider uses the Microsoft Crypto API and the RC4 algorithm.  Whether its good enough for corporate use depends on the corporation.  As I said, even if you substituted RC4 with AES and did other magic to encrypt the database in other ways, all anyone would have to do is hijack the DLL entry points and read the data right off the pipe. 

Basically there is no 100% sure way to fully protect your data as long as it resides on a machine where a potential hacker can get at it. AES, RC4, Blowfish, to a hacker with access to the code and enough smarts, are meaningless.

Robert

 

Ok, you're the expert, but afaik if the password ain't stored anywhere nor hardcoded (and it is not) the dll itself shouldn't be able to decrypt the database. So i don't understand how a hacker could access the db by just hijacking the dll entry point, without any brute force attacks involved. Just like WinRAR can't unpack an encrypted archive without the password.
Am i wrong?

Given only the database, a brute force attack would have to be made.  However, a program had to create the database initially.  Your hack goes into replacing the SQLite DLL with a hacked DLL and running your program or whatever program was used to create/modify the database to begin with.  With a hacked database engine DLL and your program running and accessing the database, I can read the blocks off the disk after your program has already supplied the necessary decryption password.

Robert

 

Exactly, sine the password will not be hardcoded, generated by the software nor stored in anyway, but choosen by the end user this won't be an issue. There will be always the need for a brute force attack.
That's why i'm concerned about how secure RC4 is compared to AES, which seems to be tough enough to be used to encrypt Top Secret data.

Anyway, thank you for your help robert :)

That's not what I was saying.  It doesn't matter where the password comes from.  Somewhere in your program, a password is supplied to the database engine, and at some point, your program reads from the encrypted database.  Those two simple things your program must do, can be intercepted at the point at which you communicate with the engine, and hacked.  It doesn't matter if its RC4 or AES, as long as someone intercepts the function calls you make which supply the password and read from the database.

If the data resides on a user's computer, and a program accesses the data, then that data can be compromised.  No exceptions.  There is no physical way to prevent it 100%, so all you can do is take reasonable precautions.  RC4 is a reasonable precaution, and works on the desktop as well as the Pocket PC -- which is why I chose it.

Robert

 

Right, but i guess i wasn't very explicit. Since the DB could be made available as download for whatever reasons access to the DB file itself will be pretty easy, but not to the PC the password-knowing-end user will use. Hench my interest in a secure encryption of the DB itself. I guess the hacker will have a hard time (involving the use of backdoors ans such stuff) using a hacked dll on a password-knowing-end user PC to access the DB itself. I say "hard time" (which obviously is relative) compared to just using a brute force attack to guess the password of the DB, which will probably be the less painfull solution in case of a weak encryption algorithm.

By no means i'm questioning your choices or skills, it's obvious you know what you're doing. Sure, there is no 100% secure way to keep data unreadable. I just wanted to know how secure RC4 is in terms of brute force attacks compared to algorithms like Rijndael. I red something about RC5 and RC6 so i guess RC4 is pretty old.

Thank you for your time :)

I'm curious about your architecture, though.  You said:

---

Since the DB could be made available as download for whatever reasons access to the DB file itself will be pretty easy, but not to the PC the password-knowing-end user will use.

---

... but why would anyone want to download or make available the DB when it couldn't be read by anyone but the password-knowing user that made it?

I haven't really done any research into the particular merits or weaknesses of RC4 ... Really all I did was try and find the most secure algorithm I could find that ran on both the desktop and the Pocket PC.

Robert

 

Yes it's a bit obscure what i'm doing :)
I try to consider all posibilities, for example there could be a rather small number of users knowing the password of a given database which is available on a website. Take a group of coworkers or a few friends who want to share something and keep unwanted guests outside. Ok there are other ways someone could do this, i'm just trying to give more options to the end user.

BTW, i still don't get why you had to add this algorithm, doesn't SQLite have a built-in crypto algorithm?

Thank you

Dr. Hipp has a crypto module for SQLite, but it is proprietary, and costs $2,000 (I think) and is not public domain.

However, due to the way he designed the library, all the "hooks" are in place inside the engine for one to build their own crypto module and plug it in.  None of the hooks are documented, but I managed to figure them out and designed my own module.

I also didn't want to step on Dr. Hipp's toes, so I went with the Microsoft Crypto-API rather than use 3rd party cross-platform encryption  source code.  My encryption module works only on Windows-based platforms, which suits the goals of this particular provider just fine. 

Robert

 

I think that doing the following:

• Create your own strong name key file
• Keep the strong name key file secure.
  
• Compile System.Data.SQLite.dll strong naming it with your own key file
• Reference this dll instead of that of SourceForge

Would make replacing the SQLite dll with a hacked dll much more difficult because it would cause load exceptions.

A very nice idea, i'll do that, thank you :)

One of the irreversable mistakes I made with the provider was to include the strong name key in the source code release.  I plan on fixing that mistake in the vNext provider.  Anyone wanting to compile the vNext provider will be forced to create their own strong name, as I won't be including my key in the source release.

Robert

 

Dear all,

Maybe it's too late to add something as the last message in this thread was more than one year old!

Anyway, I had a look to the source code of the provider (crypt.c file version 1.0.46.0) to check how exactly the database encryption was done.

What I find:

- the whole database is protected by one unique password (passphrase)

- the data in the database are arranged by pages, each page are encrypted when written and decrypted when read throught a hook registred in the sqlite3 engine

- the encryption of the pages are done using the RC4 algorithm using a default 128 bits key size (which is quite secure if well used like in SSL) in CBC mode (Chain Bloc Cipher stream mode).

- each page encryption is starting with an IV (Initialization Vector) that always have a value of zero (that may facilitate some attacks if some clear data can be guess in a page)

- the RC4 128 key is derivated from a SHA-1 hash of the password provided (that acts as passphrase in fact): the first 128 bits of the SHA-1 256 bits result are used.

- even if the Microsoft Crypto API is used, the crypto functions are very common (RC4/SHA-1) and can be easily ported to non-Windows platform.

As a conclusion, I think that the offered proctection is quite nice, the only problem maybe the non-varying Initialisation Vector for each database data page. Also, the policy of having one unique passphrase for protecting the database make the calling application to safely protect this passphrase.

I hope I didn't do any errors in my code analysis, and I hope Robert will correct me if this is the case!

Sebastien RAILLARD.

The general idea is that the encryption used in this library should not detract or replace the encryption support offered via paid services by Dr. Hipp, which is generally stronger and uses an AES algorithm.

A few notes on this ...

• The actual implementation of the encryption is done via hooks into the core library and is not something I can alter.
• The IV shouldn't matter -- all pages of the database are encrypted completely, and I believe there are zero unencrypted bytes in a page
• A passphrase can be supplied in a connection string, or binary bytes/passphrase can be called via a supplemental function on the connection object, which offers better security.

Robert