[jira] [Resolved] (VCL-1045) Method of encrypting sensitive database entries

["Andy Kurth (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/VCL-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Kurth resolved VCL-1045.
-----------------------------
    Resolution: Implemented

> 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.4.14#64029)