[
https://issues.apache.org/jira/browse/VCL-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Thompson updated VCL-1045:
-------------------------------
Description:
The new AD Domain code requires that a password be stored in the database.
There is an optional component of VMware support that requires that a password
be stored in the database as well. Aaron Coburn developed a way for the VMware
piece to be encrypted. Having a generic method for securely storing passwords
in the database that is simple to configure is really needed moving forward.
This issue outlines an automatically configured secure method of storing
passwords.
2 new tables are required:
*cryptkey*
* id
* hostid - managementnode.id or webserver.id
* hosttype - managementnode or web
* pubkey - public key from a public/private key pair
* algorithm - encryption algorithm
* algorithmoption - mode of algorithm (i.e. CBC, ECB, CTR, etc) or digest type
* keylength - length of key in bits
*cryptsecret*
* id
* cryptkeyid - reference to cryptkey.id
* secretid - id of this secret
* cryptsecret - encrypted secret key
* algorithm - encryption algorithm
* algorithmoption - mode of algorithm or digest type
* keylength - length of key in bits
Any table having a password (or similar) field will need to have that field,
which will be encrypted using a secret key, and a secretid field that
corresponds to cryptsecret.secretid.
h2. Populating cryptkey table for management nodes
When vcld starts, it should check for having an entry in cryptkey. If it
doesn't, it will generate a public/private key pair, store the private key
locally and store the public key in cryptkey.
h2. Populating cryptkey table for web servers
Either as part of installation (via install script or viewing testsetup.php) or
as a check at some event (page load, user log in, etc), a web server will check
for having a private key file, a cryptkeyid file, and an entry in cryptkey. If
it doesn't, it will generate a public/private key pair, store the private key
and cryptkey.id locally, and store the public key in cryptkey. At this point,
if it does not share a filesystem with other web servers, it wouldn't have any
cryptsecret entries. Another web server would need to detect this and populate
them. Another option is to attempt calling an XMLRPC API at the direct hostname
or IP address of another web server.
h2. Using cryptsecret
Any entry needing encrypting will need an additional field added to reference
the cryptsecret table. When a new entry is created, a new secret key must be
generated by the web server creating the entry. The field is encrypted with
this secret key. The secret key is then encrypted with any other web server's
cryptkey.pubkey with the encrypted values written to the cryptsecret table.
This allows any web server to be able to decrypt the secret key and then
decrypt the field.
When a field needs to be read, the encrypted secret is read from the
cryptsecret table, then decrypted using the system's private key that
corresponds to the public key in the cryptkey table. After the secret has been
decrypted, the secured field can be decrypted using that secret. When a value
needs to be updated, the secret key is determined as when reading, then used to
encrypt the new value.
When a reservation is made for a node that would use a secured value, the
cryptsecret table must be checked to ensure the management node processing the
reservation has an entry for the secret securing the value. If not, it will be
added at that time using the management node's cryptkey. This ensures
management nodes only have access to secured data they need, allowing
management nodes at different affiliation's sites to only have access to that
affiliation's data.
As an example, if a new record is added to the addomain table, the password
field must be encrytped. A new secret key is generated by the web code. Then,
the password is encrypted with that key. The encrypted password is written to
the database. The secret key is encrypted with any other web server's
cryptkey.publkey and each encrypted secret key is written to the cryptsecret
table.
h2. XMLRPC API function to generate new keys
An XMLRPC API function will be created named XMLRPCcheckCryptSecrets. This
function will accept a reservation id as an argument. It will ensure the
management node processing the specified reservation id has all entries in
cryptsecret needed to process the reservation. Any missing entries will be
populated.
h2. Cryptographic algorithms
Encryption algorithms, algorithm modes, and key lengths are saved in both the
cryptkey and cryptsecret tables so that future updates can easily be made.
To start out, 256 bit AES in CBC mode should be used for symmetric encryption.
4096 bit RSA with SHA512 as the digest algorithm should be used for asymmetric
encryption. Code should be written such that these would be fairly easy to
update.
was:
The new AD Domain code requires that a password be stored in the database.
There is an optional component of VMware support that requires that a password
be stored in the database as well. Aaron Coburn developed a way for the VMware
piece to be encrypted. Having a generic method for securely storing passwords
in the database that is simple to configure is really needed moving forward.
This issue outlines an automatically configured secure method of storing
passwords.
2 new tables are required:
*cryptkey*
* id
* hostid - managementnode.id or webserver.id
* hosttype - managementnode or web
* pubkey - public key from a public/private key pair
* algorithm - encryption algorithm
* algorithmoption - mode of algorithm (i.e. CBC, ECB, CTR, etc) or digest type
* keylength - length of key in bits
*cryptsecret*
* id
* cryptkeyid - reference to cryptkey.id
* secretid - id of this secret
* cryptsecret - encrypted secret key
* algorithm - encryption algorithm
* algorithmoption - mode of algorithm or digest type
* keylength - length of key in bits
Any table having a password (or similar) field will need to have that field,
which will be encrypted using a secret key, and a secretid field that
corresponds to cryptsecret.secretid.
h2. Populating cryptkey table for management nodes
When vcld starts, it should check for having an entry in cryptkey. If it
doesn't, it will generate a public/private key pair, store the private key
locally and store the public key in cryptkey.
h2. Populating cryptkey table for web servers
Either as part of installation (via install script or viewing testsetup.php) or
as a check at some event (page load, user log in, etc), a web server will check
for having a private key file, a cryptkeyid file, and an entry in cryptkey. If
it doesn't, it will generate a public/private key pair, store the private key
and cryptkey.id locally, and store the public key in cryptkey. At this point,
if it does not share a filesystem with other web servers, it wouldn't have any
cryptsecret entries. Another web server would need to detect this and populate
them. Another option is to attempt calling an XMLRPC API at the direct hostname
or IP address of another web server.
h2. Using cryptsecret
Any entry needing encrypting will need an additional field added to reference
the cryptsecret table. When a new entry is created, a new secret key must be
generated by the web server creating the entry. The field is encrypted with
this secret key. The secret key is then encrypted with any other web server's
cryptkey.pubkey with the encrypted values written to the cryptsecret table.
This allows any web server to be able to decrypt the secret key and then
decrypt the field.
When a field needs to be read, the encrypted secret is read from the
cryptsecret table, then decrypted using the system's private key that
corresponds to the public key in the cryptkey table. After the secret has been
decrypted, the secured field can be decrypted using that secret. When a value
needs to be updated, the secret key is determined as when reading, then used to
encrypt the new value.
When a reservation is made for a node that would use a secured value, the
cryptsecret table must be checked to ensure the management node processing the
reservation has an entry for the secret securing the value. If not, it will be
added at that time using the management node's cryptkey. This ensures
management nodes only have access to secured data they need, allowing
management nodes at different affiliation's sites to only have access to that
affiliation's data.
As an example, if a new record is added to the addomain table, the password
field must be encrytped. A new secret key is generated by the web code. Then,
the password is encrypted with that key. The encrypted password is written to
the database. The secret key is encrypted with any other web server's
cryptkey.publkey and each encrypted secret key is written to the cryptsecret
table.
h2. XMLRPC API function to generate new keys
An XMLRPC API function will be created named XMLRPCpopulateCryptSecrets. This
function will look for any management nodes or web servers that have entries in
cryptkey but have missing entries in cryptsecret. Entries will then be
generated in cryptsecret.
h2. Cryptographic algorithms
Encryption algorithms, algorithm modes, and key lengths are saved in both the
cryptkey and cryptsecret tables so that future updates can easily be made.
To start out, 256 bit AES in CBC mode should be used for symmetric encryption.
4096 bit RSA with SHA512 as the digest algorithm should be used for asymmetric
encryption.Code should be written such that these would be fairly easy to
update.
> Method of encrypting sensitive database entries
> -----------------------------------------------
>
> Key: VCL-1045
> URL: https://issues.apache.org/jira/browse/VCL-1045
> Project: VCL
> Issue Type: Improvement
> Components: vcld (backend), web gui (frontend)
> Reporter: Josh Thompson
> Fix For: 2.5
>
>
> The new AD Domain code requires that a password be stored in the database.
> There is an optional component of VMware support that requires that a
> password be stored in the database as well. Aaron Coburn developed a way for
> the VMware piece to be encrypted. Having a generic method for securely
> storing passwords in the database that is simple to configure is really
> needed moving forward.
> This issue outlines an automatically configured secure method of storing
> passwords.
> 2 new tables are required:
> *cryptkey*
> * id
> * hostid - managementnode.id or webserver.id
> * hosttype - managementnode or web
> * pubkey - public key from a public/private key pair
> * algorithm - encryption algorithm
> * algorithmoption - mode of algorithm (i.e. CBC, ECB, CTR, etc) or digest type
> * keylength - length of key in bits
> *cryptsecret*
> * id
> * cryptkeyid - reference to cryptkey.id
> * secretid - id of this secret
> * cryptsecret - encrypted secret key
> * algorithm - encryption algorithm
> * algorithmoption - mode of algorithm or digest type
> * keylength - length of key in bits
> Any table having a password (or similar) field will need to have that field,
> which will be encrypted using a secret key, and a secretid field that
> corresponds to cryptsecret.secretid.
> h2. Populating cryptkey table for management nodes
> When vcld starts, it should check for having an entry in cryptkey. If it
> doesn't, it will generate a public/private key pair, store the private key
> locally and store the public key in cryptkey.
> h2. Populating cryptkey table for web servers
> Either as part of installation (via install script or viewing testsetup.php)
> or as a check at some event (page load, user log in, etc), a web server will
> check for having a private key file, a cryptkeyid file, and an entry in
> cryptkey. If it doesn't, it will generate a public/private key pair, store
> the private key and cryptkey.id locally, and store the public key in
> cryptkey. At this point, if it does not share a filesystem with other web
> servers, it wouldn't have any cryptsecret entries. Another web server would
> need to detect this and populate them. Another option is to attempt calling
> an XMLRPC API at the direct hostname or IP address of another web server.
> h2. Using cryptsecret
> Any entry needing encrypting will need an additional field added to reference
> the cryptsecret table. When a new entry is created, a new secret key must be
> generated by the web server creating the entry. The field is encrypted with
> this secret key. The secret key is then encrypted with any other web server's
> cryptkey.pubkey with the encrypted values written to the cryptsecret table.
> This allows any web server to be able to decrypt the secret key and then
> decrypt the field.
> When a field needs to be read, the encrypted secret is read from the
> cryptsecret table, then decrypted using the system's private key that
> corresponds to the public key in the cryptkey table. After the secret has
> been decrypted, the secured field can be decrypted using that secret. When a
> value needs to be updated, the secret key is determined as when reading, then
> used to encrypt the new value.
> When a reservation is made for a node that would use a secured value, the
> cryptsecret table must be checked to ensure the management node processing
> the reservation has an entry for the secret securing the value. If not, it
> will be added at that time using the management node's cryptkey. This ensures
> management nodes only have access to secured data they need, allowing
> management nodes at different affiliation's sites to only have access to that
> affiliation's data.
> As an example, if a new record is added to the addomain table, the password
> field must be encrytped. A new secret key is generated by the web code. Then,
> the password is encrypted with that key. The encrypted password is written to
> the database. The secret key is encrypted with any other web server's
> cryptkey.publkey and each encrypted secret key is written to the cryptsecret
> table.
> h2. XMLRPC API function to generate new keys
> An XMLRPC API function will be created named XMLRPCcheckCryptSecrets. This
> function will accept a reservation id as an argument. It will ensure the
> management node processing the specified reservation id has all entries in
> cryptsecret needed to process the reservation. Any missing entries will be
> populated.
> h2. Cryptographic algorithms
> Encryption algorithms, algorithm modes, and key lengths are saved in both the
> cryptkey and cryptsecret tables so that future updates can easily be made.
> To start out, 256 bit AES in CBC mode should be used for symmetric
> encryption. 4096 bit RSA with SHA512 as the digest algorithm should be used
> for asymmetric encryption. Code should be written such that these would be
> fairly easy to update.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
