#1402 Multi-user / Multi-access / DBMS

[Shawn Collenburg]

This isn't a specifically a request to "do DBMS", rather a request to change they way the data is modeled & process internally.

Currently KeePass has an implicit assumption that the entire file is decrypted by a single key. I'd like to see that changed for multiple reasons:

1) Allow multi-user access, with users only having only partial access (e.g. intern, employee, supervisor)
2) Allow a single user to have multiple keys, e.g. ReallyLong1337Password -OR- ezPass + key file -OR- NT user SID. This would end the "my workgroup computer crashed, and now I can't open my NT user ID file!!!?!".
3) Allow for hidden groups & plausible deny-ability
4) Allow the backing store to be a DBMS [via plugin]

Here are my thoughts on how the data model could be rejiggered to accomplish this:

Users & their encrypted group keys -- decryptPKE(privatekey, H(salt,H(userkey)*rounds) )
<userlist>
<user><id>abc</id><Name>Bob</name><privatekey>EncryptedPrivateKey1</privatekey><key>PublicKey1</key></user>
<user><id>123</id><Name>Mary</name><privatekey>EncryptedPrivateKey2</privatekey><key>PublicKey2</key></user>
</userlist>

Per-group symmetric master keys, stored using PKE & the users's public key. User uses their private key to read (this lets Bob create a group & share it with Mary et al)
<userkeylist>
<id>abc</id><groupkey>Group1MasterKey1</groupkey> <!-- Bob -->
<id>abc</id><groupkey>Group2MasterKey2</groupkey>
<id>123</id><groupkey>Group1MasterKey2</groupkey> <!-- Mary -->
<id>123</id><groupkey>Group3MasterKey1</groupkey>
</userkeylist>

Group cipher keys, encrypted by the group master key. Shown with an optional tweak key for use in XTS mode. Bogus filler groups required to support plausible deny-ability
<grouplist>
<group><salt>abc123</salt> <groupkey>Group1CipherKey</groupkey> <groupIDkey>Group1IDKey</groupIDkey> <tweak>Group1TweakKey</tweak></group>
<group><salt>a1b2c3</salt> <groupkey>Group2CipherKey</groupkey> <groupIDkey>Group2IDKey</groupIDkey> <tweak>Group2TweakKey</tweak></group>
</grouplist>

Entries are then stored pretty much as-is. Each entry CBC encrypted by relevant GroupCipherKey (plus optional Tweak). Entries are fully opaque unless decrypted. Eacn entry has 1 block padding to start used to ID plus CBC salt generated by AES256(GroupIDKey, counter*) and must be padded to "n" bytes (since some will be longer / shorter / more history / big attachments / short attachments). Group ID used to keep performance reasonble with large databases by forward scanning for the "next" group ID to detect which GroupCipher key [[if any]] is relevant. This will also avoid clearly identifying how many groups are actually contained [*how/what is counted can be implementation specific, e.g. many DBMS tables have a single integer "ID" field uses as primary key, and doesn't even need to be unique, it just needs to change "often"] Bogus filler entries required to support plausible deny-ability.

----------

Yes, I know this is huge, and thus likely not to happen :)

+ It has also occured to me that it would be feasible to implement some or all of this via plugin acting as a "proxy". The plugin could provide "classic" 2.x XML schema & use a seperate schema to actually store the data. E.g. a multi-key proxy may be of immediate value. [UI requirements may limit what is feasible however]

Cheers, Shawn

[Shawn Collenburg]

P.S. the security framework listed in the original comment is not mature, it requires further refinement, e.g. ensuring Bob's database level key does not provide a side channel to obtaining Alice's database level key