Yes, you are right there. It won't be much good for anything else then a casual peek at the device. This is a clinical database, so it involves patients, diagnoses, medications etc. The ID data and the clinical data are stored in different tables, but even then with a simple hex editor it won't be that difficult to match the 2 up. So, I suppose the only solution is to encrypt the data. Problem is that the SQLite on the device can't decrypt and even if it could it would be a different system than the one used on the desktop. The DB file is made on the desktop and then copied to the device and on the desktop I use Olaf Schmidt's VB wrapper dhRichClient and SQLite 3.6.1. The device app is developed with Basic4PPC and that is based on .Net and uses SQLite 3.3.12. Not sure there is an easy solution there without affecting the speed of the application.
RBS -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Jay A. Kreibich Sent: 25 January 2009 18:48 To: General Discussion of SQLite Database Subject: Re: [sqlite] Lock SQLite file by overwriting bytes and then un-lock? On Sun, Jan 25, 2009 at 06:29:28PM -0000, RB Smissaert scratched on the wall: > Would it be possible to make a SQLite file un-usable by overwriting bytes in > certain places and then (via an encrypted password) make the file usable > again by putting the right bytes back in the right places? > I use a VB wrapper that can encrypt the database, but I am using this SQLite > file on a Windows Mobile device and the SQLite wrapper used there can't do > that. > I can do this quite easy by picking some fixed bytes at the beginning of the > file, but it then is too easy to pick this up by comparing with a normal > SQLite file. So, maybe I need to overwrite sqlite_master, but will it be > possible to always find the start and end of that part of the file? > Thanks for any ideas about this. To what end? What are you trying to protect against? If the database has sensitive information, especially strings, much of it can be recovered by simply dumping the database file with a hex-editor. Simply making the file unreadable by the SQLite library provides only the bare minimum of protection. If all you want to do is prevent the casual user from browsing the file, then I suppose this will work. Although your indication of scrambling the first few bytes as being "too easy" to fix seems to indicate you're after something stronger. If you really need to protect the data, you need to protect the data itself, not the access mechanism. You either need to re-write the VFS to encrypt whole database pages, or you need to encrypt the data itself before it is stored into the database. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
