Hi Jim

Jim Starkey wrote:

> Mark O'Donohue wrote:
>
>>
>>Embedded is a lost cause from a real security perspective.
>>
>
> If the database file is encrypted and reasonable key management is in
> place, it can be made secure.

It is secure, but within some limits.

For embedded you have to trust the user who is running the embedded
program and accessing the database.

In embedded use the accessing program, which is owned and run by the
user in his space, has read (and generally write) access to the
database. The program they are running has to have the decrypt key
somewhere where in the clear to access the data.

So a bit of work with the debugger will give you the decrypt key or at
least the decrypted data.

But by being encrypted the offsite backups will be safe and with
permission management users on the system other than the embedded user
can't access the database or, if encrypted, the other users can't make
sense of it.

And if the embedded program is itself a server, say part of a java
appserver (which runs as a trusted user) then, even though the appserver
is running and can access the raw data, the end user can't and the
database is secure.

So embedded is secure!

It's important to say that, since people run off with the headline not
the detail. But the embedded trust model is very different to the
server model and has certain limits.

And encrypting the data for embedded, will not stop a determined
embedded user (with legit read access) from getting at the system data.

Also Im not infallible, and am very happy to be shown I've missed something.

(The above is based on a general data encrypt key to encrypt the data in
the database. But possibly, if several users each with different keys,
no common decrypt key, and no common encrypted data, with only read
access or accessing the database only one at a time, etc..., possibly
then they couldn't read each others data, but even so it would be
tricky, and write access would quite likely ruin it).

> That said, I don't think anyone is likely
> to want to do anything with encrypted files except talk about them, but
> I'm usually wrong about this sort of thing.
>

Specifying that certain fields are stored encrypted and/or compressed
could be useful.


There are also quite common schemes now that do disk level encryption
(very popular for laptops, I think(?) IBM require all their corporate
laptops to do this now ) and the filesystem is layered over it. They
require a key to be entered when rebooted to give access to the disk.

Performance seems quite reasonable, from what I've seen.

Cheers

Mark