General

Re: SQLite Encryption Strength?

Robert Simpson — Tue, 28 Jul 2009 21:02:27 GMT

The .NET provider uses RC4 encryption. The entire file is encrypted, including the metadata. SQLite the engine may store unencrypted pages in its internal cache, but I don't really know for sure.

The bottom line is that nothing is safe from a hacker who has your binaries and database on his/her computer and is determined to read your data.

It is impossible to design an unhackable program that is designed to run on a local computer. Anytime a hacker has access to a debugger and locally-running code, you are vulnerable in some fashion or another.

Re: SQLite Encryption Strength?

IronyofLife — Tue, 28 Jul 2009 20:41:52 GMT

First of all, thanks to you for creating this wonderful package and making it available to all. I have successfully integrated your library into my application. I do realize that this thread is close to 2 years old. Hope you can reply to my question. Sqlite database is a flat file and as such does not offer much protection. Encrypting it makes it harder to read and depending on the strength of the encryption technology, it may or may not be possible to hack it by brute force. However, SQLite stores pages of data in memory and in the case of encrypted database, is the data in the pages encrypted and decryption happens when it is actually queried? In other words how secure is encryption for a determined hacker employing tools to read the data from memory. Thanks very much in advance.

Re: SQLite Encryption Strength?

Robert Simpson — Mon, 15 Oct 2007 14:40:42 GMT

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

Re: SQLite Encryption Strength?

sraillard — Mon, 15 Oct 2007 12:55:24 GMT

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.

Re: SQLite Encryption Strength?

Robert Simpson — Thu, 14 Sep 2006 14:34:18 GMT

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

Re: SQLite Encryption Strength?

r41n — Thu, 14 Sep 2006 09:13:49 GMT

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

Re: SQLite Encryption Strength?

SqlRanger — Thu, 14 Sep 2006 07:32:51 GMT

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.

Re: SQLite Encryption Strength?

Robert Simpson — Wed, 13 Sep 2006 15:36:18 GMT

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

Re: SQLite Encryption Strength?

r41n — Wed, 13 Sep 2006 14:56:35 GMT

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

Re: SQLite Encryption Strength?

Robert Simpson — Wed, 13 Sep 2006 14:42:43 GMT

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

Re: SQLite Encryption Strength?

r41n — Wed, 13 Sep 2006 09:40:52 GMT

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 :)

Re: SQLite Encryption Strength?

Robert Simpson — Wed, 13 Sep 2006 01:02:16 GMT

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

Re: SQLite Encryption Strength?

r41n — Tue, 12 Sep 2006 23:32:37 GMT

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 :)

Re: SQLite Encryption Strength?

Robert Simpson — Tue, 12 Sep 2006 20:21:35 GMT

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

Re: SQLite Encryption Strength?

r41n — Tue, 12 Sep 2006 19:52:57 GMT

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?