------------------------------------------------------------------------------- Key Storage Systems In many ways a "Password Vault" (storing website and account passwords) is a simplistic version of this. Strong passwords are stored and used for the remote system, letting you use a single user password, (that should be kept local) for the password vault itself. (See below) But true "Key Storage Systems" can do a lot more than just be a "Password Vault" for web site passwords. They can hold the passwords for Encrytped files systems, and can also store the extra information needed to mount such systems. It is not meant that a single password is used to unlock everything, but only to unlock the information needed to do some purpose. That is the user gives a password that unlocks a specific 'Key File' within the 'Key Store', which then provides all the information needed to, say, mount an encrypted file system. That includes a strong (randomaly generated) master password for the file system, the commands needed to mount the file system, the encrypted data location, where it will normally be mounted, and perhaps even the configuration file needed for the encryption. This extra level of indirection allows the real data to be encrypted with a strong, purely randomly generated key, while storing that key and all the other configuation information in a completely separate area under the users password. The user does not need to personally know all that hard to remember information, such as the actual random password, or the details of where and how the data or file system is stored. By using 'key files', the users password can be changed easilly, simply by re-encrypting the 'key file' without needing to decrypt, copy, and re-encrypt the actual data, which for a large filesystem can take a very long time. Basically the hard to remember master password, and encryption remains the same. You can even give different users their own 'key file' with their own separate password, to decrypt the same data. Individual users do not need to share the password, and administaions can control access via each users individual 'key file', though one user could remove access to the other users. This two-stage password indirection is used by LUKS disk encryption and is presented in the paper... "TKS1, An anti-forensic, two level, and iterated key setup scheme." http://clemens.endorphin.org/TKS1-draft.pdf Also see.. Dual password encryption with EncFS http://magazine.redhat.com/2007/06/13/dual-password ------------------------------------------------------------------------------- Password Vaults Password Vaults are basically encrypted password file that hold all the password you use for a multitude of remote accounts and more specifically Web Servers. Many of these are themselves are network served files so you have access to your password from multiple devices and locations. The techniques of such systems ensures that the password needed is kept local, and not passed to the remote hosting service, however it seems to me it would be trivial for them to collect that master password using 'fake' web sites. So really though they make it seem secure, their is still some level of trust involved. ------------------------------------------------------------------------------- Gnome Keyring This is a daemon holding a encrypted data store open, so that you have access to passwords or other secrets, at least for the duration the user is logged in. For example passwords for web pages, network VPN connections, or logins on other computers. This is a more permanent store (password vault), as it is saved to disk, so can store secrets between sessions, and does not have any timeout facility for the 'secrets' being stored. The password to unlock the encrypted store is typically the users login password, but can be bypassed by setting a empty password. It also relies on the "dbus" interprocess communication system being active. Which is part of the gnome window manager setup, so it only works while the user is logged in, and does not work well with remote systems. See "keyring_gnome.txt" for more information. ------------------------------------------------------------------------------- KS - Key Store Program Using the above 'two-stage password indirection' idea I developed "ks" (written in perl) that understands running EncFS, CryFS, etc, to mount file systems using a completely randomised password. https://antofthy.gitlab.io/software/#ks 'Key Store' stores encrypted 'key files' in a file system such as a removable USB stick, so that you can also include some physical security of the access keys, if you so desire. The key files not only holds a totally random master key, but also all the other details of the encryption: such as the actual ".encfs6.xml" configuration file to use, the location of the encrypted data, optionally where it should be mounted (if desired). It has extra benifits too. The command used to to access (mount or display) the data, is also stored in the key files. So it is not specifically limited to just EncFS. You can set up a key file that if used, runs a command that will destroy the encryption information across the whole keystore, preventing it from being used. For example... The "key files" themselves are basically encrypted files, that can be access using a "label". For example "ks -e webpwd" would let you edit a specific "key file" that for example holds all your web site passwords. Or it could be any other simple text file of data, like your ultra secret cookie recipe. in this situation the "key file" is itself is the data, with the master key and mount information not being used. The keystore can hold a encrypted shell script to be run, without making the shell script itself readable (unless you have the password). It could be used to unlock a Web Password Vault, such as LastPass. Or it could mount a Encrypted zfile system, be it EncFs, CryFS, Jungle Drive, and so on. -------------------------------------------------------------------------------