Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 19:31, Alex Peshkoff wrote: >> >I think we need to step back and decide what the real problem is trying to >> >be solved!!! > Yes. In this case the "real problem" is a ticket in tracker with feature request. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> > Again, I feel that they issue of client/server connection encryption and > database encryption are being co-mingled. > > > > Database encryption is about the engine's ability to access/work with a > database, there should be absolutely no client dependency. > > More than 80% of encryption cases are expected to be applications > distributed together with databases. They are usually single-user and often > use the embedded Firebird. In this case it's really logical to allow the > client > application to manage the key. Then, this is solution should be described in the context of how the embedded engine will support encryption. This thread was about SS/other engines. Are you saying that the only mode that database encryption will work, is the one which satisfies only 80% of the installs? What solution is proposed for the other 20%? How would ODBC/JDBC connections to an encrypted database using an embedded engine work in the proposed solution? Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 20:27, Leyne, Sean wrote: > > Are you saying that the only mode that database encryption will work, is the > one which satisfies only 80% of the installs? Nope. You've been told that *both* key management modes (purely server-side and via client callback) are supported. You asked why client needs to be in the game at all. I've replied with a use case. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> Sometimes it's highly desired not to let standard tools access encrypted > database - first of all for distributed databases. That is what user credentials/grants are for. That is not the role of database encryption. Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> 2 main usages of database encryption: > - protect distributed database from unauthorized access, Actually, no! Access control is not what database encryption is about. > - protect database from access if server became physically available to third > party (something like stolen). Physical security is not a problem that database encryption is designed to solve. I think we need to step back and decide what the real problem is trying to be solved!!! Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 18:27, Leyne, Sean wrote: > this is solution should be described in the context of how the embedded > engine will support encryption. This thread was about SS/other engines. There is no such things in Firebird 3. Only one engine is used everywhere. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 11/18/2015 05:45 PM, Adriano dos Santos Fernandes wrote: > On 18/11/2015 12:36, Alex Peshkoff wrote: >> On 11/18/2015 04:44 PM, Adriano dos Santos Fernandes wrote: >>> On 18/11/2015 11:40, Alex Peshkoff wrote: On 11/17/2015 07:52 PM, Adriano dos Santos Fernandes wrote: > On 17/11/2015 14:48, Dimitry Sibiryakov wrote: >> 17.11.2015 17:40, Leyne, Sean wrote: >>> For me, the sequence of operations for accessing a database would be: >>> >>> - Client initiates connection to remote server, requesting access to >>> database XYZ.fdb (there is nothing new in the connection string other >>> than what is available now) >>> - engine tries to open database XYZ.fdb and read header page >>> - engine determines that header page reads "I am encrypted and need key >>> with name = ABCD" >>> - engine determines (through server/database config settings) which >>> plug-in to use >>> - engine loads/calls plug-in asking "I have database which needs key >>> with name = ABCD, are you able/ready to work?" >>> - if plug-in says "Yes", then the engine proceeds with database open, >>> and all non-header page operations are channeled through the plug-in >>> - if plug-in says "No", then engine stops the database open, and >>> returns error to client. >> Currently it is this way: >> >> - Client application set callback for providing a key > Why a callback instead of directly passing it to attach/create? > > Hot does different clients (my application x IBExpert) will work with an > encrypted database if the applications are wrote by different developers > and plugins are not standard? > Sometimes it's highly desired not to let standard tools access encrypted database - first of all for distributed databases. >>> Well, but sometimes it is! >>> >>> Applications developers will need to develop their own tools to work >>> with encrypted databases outside their applications? >> 2 main usages of database encryption: >> - protect distributed database from unauthorized access, >> - protect database from access if server became physically available to >> third party (something like stolen). >> >> In first case it's clear - IBExpert should not work at all. > Not true. If I have my certificate in Windows and need to put a password > to access it, it doesn't matter if it's done by my application or IBExpert. For you may be not, but for authors of such database there is bug difference. There application allows just to browse db, IBExpert may backup it in unencypted way. > If the design is to disallow this, the design is weak as that could be > easily bypassed with a custom fbclient. > Certainly could - therefore this can be used only with embedded system. In this case application can easily check what build of firebird is used nad when detecting something non-std do not work with it. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> > Are you saying that the only mode that database encryption will work, is > the one which satisfies only 80% of the installs? > > Nope. You've been told that *both* key management modes (purely server- > side and via client callback) are supported. You asked why client needs to be > in the game at all. I've replied with a use case. I don't recall a reply saying that both modes would be supported. I wish that Dimitry S would have been clearer in his posts... The thread subject is about SS mode, not embedded... my post described a server-side only mode, his reply was about client side... What is the sequence of operations for server-side key management? Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 18:55, Leyne, Sean wrote: > What is the sequence of operations for server-side key management? Crypt plugin either get the key somehow itself, or ask all configured key holder plugins for it. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 11/18/2015 08:27 PM, Leyne, Sean wrote: > >>> Again, I feel that they issue of client/server connection encryption and >> database encryption are being co-mingled. >>> Database encryption is about the engine's ability to access/work with a >> database, there should be absolutely no client dependency. >> >> More than 80% of encryption cases are expected to be applications >> distributed together with databases. They are usually single-user and often >> use the embedded Firebird. In this case it's really logical to allow the >> client >> application to manage the key. > Then, this is solution should be described in the context of how the embedded > engine will support encryption. This thread was about SS/other engines. For distributed databases I see no solution for non-embedded engine. In embedded case application can validate on the run correctness of loaded components (yvalve, engine, plugins) and depending upon it provide or not a key to them. In remote case it will have to send secret key over the wire to probably modified engine. No idea how can it be secure. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 11/18/2015 08:45 PM, Leyne, Sean wrote: >> 2 main usages of database encryption: >> - protect distributed database from unauthorized access, > Actually, no! Access control is not what database encryption is about. Sean, may be "access" is bad word here. I've meant that _only_ special application, distributed together with database, must have access to it. "unauthorized access" here is _any_ access not from that app. > >> - protect database from access if server became physically available to third >> party (something like stolen). > Physical security is not a problem that database encryption is designed to > solve. Why not? It's one of problems database encryption can decide. Certainly, it can be decided by filesystem encryption, but database encryption is better in some aspects than all filesystem encryption. For example it may be done on the fly. > > I think we need to step back and decide what the real problem is trying to be > solved!!! Yes. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 19:05, Alex Peshkoff wrote: > In remote case it will have to send secret key over > the wire to probably modified engine. No idea how can it be secure. Server security is not our thing. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 18/11/2015 11:40, Alex Peshkoff wrote: > On 11/17/2015 07:52 PM, Adriano dos Santos Fernandes wrote: >> On 17/11/2015 14:48, Dimitry Sibiryakov wrote: >>> 17.11.2015 17:40, Leyne, Sean wrote: For me, the sequence of operations for accessing a database would be: - Client initiates connection to remote server, requesting access to database XYZ.fdb (there is nothing new in the connection string other than what is available now) - engine tries to open database XYZ.fdb and read header page - engine determines that header page reads "I am encrypted and need key with name = ABCD" - engine determines (through server/database config settings) which plug-in to use - engine loads/calls plug-in asking "I have database which needs key with name = ABCD, are you able/ready to work?" - if plug-in says "Yes", then the engine proceeds with database open, and all non-header page operations are channeled through the plug-in - if plug-in says "No", then engine stops the database open, and returns error to client. >>> Currently it is this way: >>> >>> - Client application set callback for providing a key >> Why a callback instead of directly passing it to attach/create? >> >> Hot does different clients (my application x IBExpert) will work with an >> encrypted database if the applications are wrote by different developers >> and plugins are not standard? >> > Sometimes it's highly desired not to let standard tools access encrypted > database - first of all for distributed databases. > > Well, but sometimes it is! Applications developers will need to develop their own tools to work with encrypted databases outside their applications? Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 11/17/2015 07:48 PM, Dimitry Sibiryakov wrote: > 17.11.2015 17:40, Leyne, Sean wrote: >> For me, the sequence of operations for accessing a database would be: >> >> - Client initiates connection to remote server, requesting access to >> database XYZ.fdb (there is nothing new in the connection string other than >> what is available now) >> - engine tries to open database XYZ.fdb and read header page >> - engine determines that header page reads "I am encrypted and need key with >> name = ABCD" >> - engine determines (through server/database config settings) which plug-in >> to use >> - engine loads/calls plug-in asking "I have database which needs key with >> name = ABCD, are you able/ready to work?" >> - if plug-in says "Yes", then the engine proceeds with database open, and >> all non-header page operations are channeled through the plug-in >> - if plug-in says "No", then engine stops the database open, and returns >> error to client. > Currently it is this way: > > - Client application set callback for providing a key > - client application initiates connection to a database > - engine reads header > - engine reads crypt-plugin name from header > - engine loads the plugin > - plugin ask all configured key holders "does anybody have a key for me?" > - keyholder either can give the key or call application's callback to get > confirmation > beforehand > - if any piece of the chain raise error, connect fail > - if provided key is wrong, engine crash > I must pay attention that this is how things are done in trivial _sample_ of crypt plugin, provided with fb3. But even with it it's not _required_ to use all this steps exactly. This sample maybe configured making keyholder (or crypt) plugin read encryption key from configuration file instead calling someone else for it. Certainly, that's not a way to store keys in reality but taking into an account that 1-byte key is also not good for reality seems ok for demonstration. In general case crypt plugin may ask key holder(s) to provide a key or do it in some other way. Key holder also not enforced to use callback to client - it may get a key in any pther manner, for example from key server on LAN. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 11/17/2015 07:52 PM, Adriano dos Santos Fernandes wrote: > On 17/11/2015 14:48, Dimitry Sibiryakov wrote: >> 17.11.2015 17:40, Leyne, Sean wrote: >>> For me, the sequence of operations for accessing a database would be: >>> >>> - Client initiates connection to remote server, requesting access to >>> database XYZ.fdb (there is nothing new in the connection string other than >>> what is available now) >>> - engine tries to open database XYZ.fdb and read header page >>> - engine determines that header page reads "I am encrypted and need key >>> with name = ABCD" >>> - engine determines (through server/database config settings) which plug-in >>> to use >>> - engine loads/calls plug-in asking "I have database which needs key with >>> name = ABCD, are you able/ready to work?" >>> - if plug-in says "Yes", then the engine proceeds with database open, and >>> all non-header page operations are channeled through the plug-in >>> - if plug-in says "No", then engine stops the database open, and returns >>> error to client. >> Currently it is this way: >> >> - Client application set callback for providing a key > Why a callback instead of directly passing it to attach/create? > > Hot does different clients (my application x IBExpert) will work with an > encrypted database if the applications are wrote by different developers > and plugins are not standard? > Sometimes it's highly desired not to let standard tools access encrypted database - first of all for distributed databases. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 15:20, Adriano dos Santos Fernandes wrote: > What about the callback set in the dispatcher? Utilities that are not aware of crypt key don't ever set it. Besides, it is up to key holder plugin whether to call it. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 11/18/2015 04:44 PM, Adriano dos Santos Fernandes wrote: > On 18/11/2015 11:40, Alex Peshkoff wrote: >> On 11/17/2015 07:52 PM, Adriano dos Santos Fernandes wrote: >>> On 17/11/2015 14:48, Dimitry Sibiryakov wrote: 17.11.2015 17:40, Leyne, Sean wrote: > For me, the sequence of operations for accessing a database would be: > > - Client initiates connection to remote server, requesting access to > database XYZ.fdb (there is nothing new in the connection string other > than what is available now) > - engine tries to open database XYZ.fdb and read header page > - engine determines that header page reads "I am encrypted and need key > with name = ABCD" > - engine determines (through server/database config settings) which > plug-in to use > - engine loads/calls plug-in asking "I have database which needs key with > name = ABCD, are you able/ready to work?" > - if plug-in says "Yes", then the engine proceeds with database open, and > all non-header page operations are channeled through the plug-in > - if plug-in says "No", then engine stops the database open, and returns > error to client. Currently it is this way: - Client application set callback for providing a key >>> Why a callback instead of directly passing it to attach/create? >>> >>> Hot does different clients (my application x IBExpert) will work with an >>> encrypted database if the applications are wrote by different developers >>> and plugins are not standard? >>> >> Sometimes it's highly desired not to let standard tools access encrypted >> database - first of all for distributed databases. >> >> > Well, but sometimes it is! > > Applications developers will need to develop their own tools to work > with encrypted databases outside their applications? 2 main usages of database encryption: - protect distributed database from unauthorized access, - protect database from access if server became physically available to third party (something like stolen). In first case it's clear - IBExpert should not work at all. In second case it should work, but it's not reasonable to store key on clients cause it will be enough to have single client machine (together with server) to solve access problem. Another way to provide a key should be used. I.e. I do not see need in callback to standard utilities, but if needed we certainly can a call to key holder in yvalve. But personally I prefer not do it cause it may be treated as suggestion to use bad design. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 15:36, Alex Peshkoff wrote: > In second > case it should work, but it's not reasonable to store key on clients > cause it will be enough to have single client machine (together with > server) to solve access problem. Another way to provide a key should be > used. It is enough to add a couple of pieces into the picture: put the key to a file and the file - to EFS/secure flash stick. Then to get access to the database one must collect server, client, stick and a person that know pin-code/has a right fingerprint. I almost done changes that will allow to do all that by plugins only. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
18.11.2015 14:44, Adriano dos Santos Fernandes wrote: > Applications developers will need to develop their own tools to work > with encrypted databases outside their applications? No, just use appropriate key holder to provide the key for every connect, including standard utilities. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 18/11/2015 11:57, Dimitry Sibiryakov wrote: > 18.11.2015 14:44, Adriano dos Santos Fernandes wrote: >> Applications developers will need to develop their own tools to work >> with encrypted databases outside their applications? >No, just use appropriate key holder to provide the key for every connect, > including > standard utilities. > What about the callback set in the dispatcher? Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 18/11/2015 12:36, Alex Peshkoff wrote: > On 11/18/2015 04:44 PM, Adriano dos Santos Fernandes wrote: >> On 18/11/2015 11:40, Alex Peshkoff wrote: >>> On 11/17/2015 07:52 PM, Adriano dos Santos Fernandes wrote: On 17/11/2015 14:48, Dimitry Sibiryakov wrote: > 17.11.2015 17:40, Leyne, Sean wrote: >> For me, the sequence of operations for accessing a database would be: >> >> - Client initiates connection to remote server, requesting access to >> database XYZ.fdb (there is nothing new in the connection string other >> than what is available now) >> - engine tries to open database XYZ.fdb and read header page >> - engine determines that header page reads "I am encrypted and need key >> with name = ABCD" >> - engine determines (through server/database config settings) which >> plug-in to use >> - engine loads/calls plug-in asking "I have database which needs key >> with name = ABCD, are you able/ready to work?" >> - if plug-in says "Yes", then the engine proceeds with database open, >> and all non-header page operations are channeled through the plug-in >> - if plug-in says "No", then engine stops the database open, and returns >> error to client. > Currently it is this way: > > - Client application set callback for providing a key Why a callback instead of directly passing it to attach/create? Hot does different clients (my application x IBExpert) will work with an encrypted database if the applications are wrote by different developers and plugins are not standard? >>> Sometimes it's highly desired not to let standard tools access encrypted >>> database - first of all for distributed databases. >>> >>> >> Well, but sometimes it is! >> >> Applications developers will need to develop their own tools to work >> with encrypted databases outside their applications? > 2 main usages of database encryption: > - protect distributed database from unauthorized access, > - protect database from access if server became physically available to > third party (something like stolen). > > In first case it's clear - IBExpert should not work at all. Not true. If I have my certificate in Windows and need to put a password to access it, it doesn't matter if it's done by my application or IBExpert. If the design is to disallow this, the design is weak as that could be easily bypassed with a custom fbclient. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> > Why should the **connection** provide the key? > >Because looking for a key is not a work for a lock. >And keeping the key under a door mat is also generally a bad idea. Perhaps you are referring to a different "connection" than I am. Could you/someone please confirm the sequence of events in the accessing an encrypted database. Cus when I read/here "connection", I think of the link between the client session and the server process. For me, the sequence of operations for accessing a database would be: - Client initiates connection to remote server, requesting access to database XYZ.fdb (there is nothing new in the connection string other than what is available now) - engine tries to open database XYZ.fdb and read header page - engine determines that header page reads "I am encrypted and need key with name = ABCD" - engine determines (through server/database config settings) which plug-in to use - engine loads/calls plug-in asking "I have database which needs key with name = ABCD, are you able/ready to work?" - if plug-in says "Yes", then the engine proceeds with database open, and all non-header page operations are channeled through the plug-in - if plug-in says "No", then engine stops the database open, and returns error to client. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
>Theoretical question: must every connection provide a valid key, or first > connection unlock the database for everyone? Why should the **connection** provide the key? The engine should be able to find/validate the key on its own, when the database file is _opened_. This would mean that for SS and SC the key would be validated only once, for Classic on each connection (since each instance opens the database) The connection is simply asking to access the database... Sean P.S.Again the language of the question is framing database encryption as dependent on client-server connectivity. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
17.11.2015 16:26, alex wrote: > This depends upon crypt key holder plugin. Right. But to make it possible, Firebird code must provide an opportunity. In terms of code the question is "should be setKey() called only after plugin's load or for every new attachment no matter if the plugin was already loaded by others". -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
17.11.2015 17:47, Dimitry Sibiryakov пишет: > Hello, All. > > Theoretical question: must every connection provide a valid key, or first > connection > unlock the database for everyone? > можно сделать и так и сяк - определяется holder-ом (я сегодня почти не на раюоте завтра постараюсь подробней написать) -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
17.11.2015 16:18, Leyne, Sean wrote: > Why should the **connection** provide the key? Because looking for a key is not a work for a lock. And keeping the key under a door mat is also generally a bad idea. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Several connections to encrypted database in SS mode
Hello, All. Theoretical question: must every connection provide a valid key, or first connection unlock the database for everyone? -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
On 17/11/2015 14:48, Dimitry Sibiryakov wrote: > 17.11.2015 17:40, Leyne, Sean wrote: >> For me, the sequence of operations for accessing a database would be: >> >> - Client initiates connection to remote server, requesting access to >> database XYZ.fdb (there is nothing new in the connection string other than >> what is available now) >> - engine tries to open database XYZ.fdb and read header page >> - engine determines that header page reads "I am encrypted and need key with >> name = ABCD" >> - engine determines (through server/database config settings) which plug-in >> to use >> - engine loads/calls plug-in asking "I have database which needs key with >> name = ABCD, are you able/ready to work?" >> - if plug-in says "Yes", then the engine proceeds with database open, and >> all non-header page operations are channeled through the plug-in >> - if plug-in says "No", then engine stops the database open, and returns >> error to client. >Currently it is this way: > > - Client application set callback for providing a key Why a callback instead of directly passing it to attach/create? Hot does different clients (my application x IBExpert) will work with an encrypted database if the applications are wrote by different developers and plugins are not standard? Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> - Client application set callback for providing a key I don't understand why client needs to know anything about whether database is encrypted or not. Certainly, MS SQL server doesn't require clients to know such details... Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
17.11.2015 18:01, Leyne, Sean wrote: >> - Client application set callback for providing a key > I don't understand why client needs to know anything about whether database > is encrypted or not. This step depends on implementation of KeyHolder plugin and may be not required. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
17.11.2015 17:40, Leyne, Sean wrote: > For me, the sequence of operations for accessing a database would be: > > - Client initiates connection to remote server, requesting access to database > XYZ.fdb (there is nothing new in the connection string other than what is > available now) > - engine tries to open database XYZ.fdb and read header page > - engine determines that header page reads "I am encrypted and need key with > name = ABCD" > - engine determines (through server/database config settings) which plug-in > to use > - engine loads/calls plug-in asking "I have database which needs key with > name = ABCD, are you able/ready to work?" > - if plug-in says "Yes", then the engine proceeds with database open, and all > non-header page operations are channeled through the plug-in > - if plug-in says "No", then engine stops the database open, and returns > error to client. Currently it is this way: - Client application set callback for providing a key - client application initiates connection to a database - engine reads header - engine reads crypt-plugin name from header - engine loads the plugin - plugin ask all configured key holders "does anybody have a key for me?" - keyholder either can give the key or call application's callback to get confirmation beforehand - if any piece of the chain raise error, connect fail - if provided key is wrong, engine crash -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
Hello! Tuesday, November 17, 2015, 6:26:04 PM, you wrote: >> The engine should be able to find/validate the key on its own, when the >> database file is _opened_. a> This depends upon crypt key holder plugin. Even in SS it may be written a> in a way forcing each connection to provide valid key (this ensures no a> connections from std tools to database with restricted information). a> Even in CS it may be written in a way when first connection with valid a> key opens access for all others (using shared memory). As I remember correctly, InterBase does - there must by special user SYSDSO, who creates System Encryption Password and then keys to encrypt database or columns - while DB is on the same computer, where SEP was generated, nobody needs to specify it to connect to encrypted database. - when DB is moved to another computer SEP is not "default" anymore and connection need to specify it explicitly, in addition to username/password. -- Sincerely, Dmitry Kuzmenko -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
> 17.11.2015 18:01, Leyne, Sean wrote: > >> - Client application set callback for providing a key > > I don't understand why client needs to know anything about whether > database is encrypted or not. > >This step depends on implementation of KeyHolder plugin and may be not > required. Again, I feel that they issue of client/server connection encryption and database encryption are being co-mingled. Database encryption is about the engine's ability to access/work with a database, there should be absolutely no client dependency. Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Several connections to encrypted database in SS mode
17.11.2015 23:48, Leyne, Sean wrote: > > Again, I feel that they issue of client/server connection encryption and > database encryption are being co-mingled. > > Database encryption is about the engine's ability to access/work with a > database, there should be absolutely no client dependency. More than 80% of encryption cases are expected to be applications distributed together with databases. They are usually single-user and often use the embedded Firebird. In this case it's really logical to allow the client application to manage the key. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
