On 11/14/2015 3:51 PM, Leyne, Sean wrote: > Jim, > >> If there's any interest, I have some ideas on how to handle unattended >> startup of an encrypted database that we could kick around. > I would like to have such a discussion, since I have found the discussion of > the whole "key holder" discussion a little obtuse and seemingly mixing remote > client/connection security with database file encryption.
So here's a simple scheme. The basic idea of a redundant set of lightweight key servers running at various points in the network. When a database wants to start up, it runs through a list of key server addresses looking for one that is actually running. If it finds one, it establishes a secure connection and asks for the decryption key. The key server notes the IP address of the requester and returns the appropriate key. Probably a good idea to toss in a database name as well. While's it possible to fake the originator IP address with UDP, I don't think it's possible with TCP. The connection to the key server is secured by SRP and is stored in the database configuration. If you're concerned about the database file being exposed, you have assume the SRP password is blown, so it's used only to establish a session password. This would otherwise be wide open to man in the middle attacks, but since the key server is using the connection IP to identify the client, man in the middle isn't a problem unless it's originating from the database node. If you have a bad guy running loose on your machines, you have other problems as well (in other words, I haven't a clue how to know if a remote system has been hopeless compromised -- fatal flaw? Maybe <insert opinion here>. The key server would used a hardened vault for storing <IP, database name, SRP verifier, key> quads, and would be started manually with a vault password. The vault could be flooded around, possibly with different vault passwords. Since key server startup time is of no significance, it could be configured to take a full second or two to validate the vault password, making a brute force attack infeasible with a halfway decent password. The scheme is no good if a bad guy has taken over a machine to the degree that he can break file access security and can run programs accessing the network. Maybe somebody has some ideas on how to detect where a once trusted machine has been captured. > > In my own thinking (perhaps naïve) about how encryption would be added to a > database, I had thought the following: > > 1- The database header page would be stored unencrypted (as it is today), > allowing the basic db details to be visible to the engine. > > 2- A "cert name/alias" would be added to the header, which would point to the > key/cert that would be stored in an appropriate/secure location on the server > (which would be defined in engine config or database ini/config). > > 3- Further the same cert would be (by default) used when any backup that > would be created (unless a "unencrypted" backup was requested), and therefore > the cert would also be necessary to restore the database. > > Using the above approach, a database/backups would be portable and would be > accessible as long as the server contains the appropriate cert. > > As for the issue of cert security, being a Windows guy, I had thought that > the native cert functions would allow for certs to be securely loaded and > stored in one of the cert stores, since in order to load/import a cert the > private key would be required. > > > Sean > > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
