Hi Steve, > ok thought so, was missing the "literal" yaml key pair entry, is there > somewhere that defines how to setup a password group like this (google foo > didn't find any examples), and other examples (and documentation) of > different password group types?
See https://openxpki.readthedocs.io/en/latest/reference/configuration/realm.html#secret-groups In case the documentation does not make this clear, let me summarize the underlying logic: The following applies to software protected keys: - each crypto token references exactly one secret group - all crypto tokens referencing the same secret group are expected to use the same passphrase, it is your responsibility as a PKI admin to make sure that all tokens referencing the secret group can be unlocked by the underlying secret - for an encrypted software key a secret group can be - a literal passphrase - a simple passphrase (entered in full via the GUI) - a split secret (k/n Shamirs Secret Sharing; note that tha latest GUI rework likely broke this feature, I have not tested it in a long time) > is there a way instead of defining a literal clear string, that it can be > hashed or salted so its not stored in the YAML in clear text? in some PCI-DSS > environments, clear text, un-hashed passwords are a no-no (my target > environments) As a general rule you should not store a passphrase in any configuration if this is a sensitive environment. Being able to do so in OpenXPKI is for testing purposes and primarily in order to allow querying passphrases at runtime via a Connector and e. g. KeyNanny. If you have a security sensitive environment you should consider using a HSM and not waste your time with software keys and esoteric reasoning about cleartext passphrases. Side note: we have a long established PKI running at a major financial organization which does not have a single password (including database, LDAP and other credentials) in its configuration, all sensitive information read from a KeyNanny connector at runtime. CA and Datapool keys as well as the KeyNanny keys are HSM protected. It is a somewhat complex setup, but it can absolutely be done, and if done properly it is stable. The system has been running like that for many years (including datavault cert rollovers and service password changes) now. > Related to the password, on import, are all 3 needing to be defined like your > example, just for the import? I presume after import that they are stored in > the data valult? I've seen references of encrypting the key in the data vault > (or the password of the key protected by the vault), but anyone with access > to the Database can get the password. By its original design, OpenXPKI only stored certificates in its database. Keys were expected to be located on disk or, better yet, protected by a HSM where they belong. Lately we have been asked to provide the possibility to locate keys in the OpenXPKI datapool, so we implemented this. You don't have to use this feature, but if you do so, you will have to make sure that the datapool encryption can be unlocked after system startup. This again boils down on the protection of at least one key. If you want automatic startup, you either have to have a literal passphrase via the configuration/via a connector, OR, again, use a HSM (which is, again, the right way to do it if you are serious about security). > So how is the password protected in the datavault? Documentation somewhere I > might have missed? If you store sensitive data in the datavault (via an encrpyted datapool entry) there is a hybrid approach to store the data: the data is encrypted with a random AES key which in turn is encrypted to the datavault certificate. To unlock the system, the datavault key has to be unlocked so the AES key can be decrypted. The datavault AES key is then kept in memory for the duration of the process (it is reused during the validity period of the vault certificate). Cheers Martin _______________________________________________ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
