vcl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Thompson (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (VCL-1045) Method of encrypting sensitive database entries
Date Thu, 25 May 2017 16:56:04 GMT

     [ 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, then the field can be decrypted.  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
should be checked to ensure the management node processing the reservation has an entry for
the secret. 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 separate sites to not have access to some sets of secured 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.

  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.

3 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

*cryptsecret*
* id
* cryptkeyid - reference to cryptkey.id
* secretid - id of this secret
* cryptsecret - encrypted secret key

*webserver*
* id
* host - hostname or IP address of web server
* checkin - datetime updated each time a user logs in (rather than updating every page load)

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, store the public key in
cryptkey, and call an XMLRPC API method a web server to generate any needed entries in cryptsecret
(more on this later).

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 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. At this point, it wouldn't have any cryptsecret
entries. Another web server or a management node would need to detect this and populate them.
Alternatively, vcld --setup could be used to populate this. Another option is to attempt calling
the 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 system (vcld
or web) creating the entry. The field is encrypted with this secret key. The secret key is
then encrypted with every systems' cryptkey.pubkey with the encrypted values written to the
cryptsecret table. This allows any system 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, then the field can be decrypted.  When a value needs to be updated, the
secret key is determined as when reading, then used to encrypt the new value. 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 each 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
Symmetric and asymmetric algorithms along with key lengths are yet to be determined. 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, then the field can be decrypted.  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 should be checked to ensure the management node processing the reservation has an entry
for the secret. 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 separate sites to not have access to some sets of secured 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.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message