> -----Original Message----- > From: Vijayendra Bhamidipati [mailto:vijayendra.bhamidip...@citrix.com] > Sent: Wednesday, 20 June 2012 12:16 > To: 'cloudstack-dev@incubator.apache.org' > Cc: Kelven Yang; Sateesh Chodapuneedi; Devdeep Singh > Subject: Query regarding where to store encryption keys > > Hi Team, > > This is with reference to bug CS-15151 > (http://bugs.cloudstack.org/browse/CS-15151). I have some questions and > it would be great if you could share your knowledge and suggestions. > > We have a need to store credentials required to login to vCenter, so > that that cloudstack management server can log in and talk to it. We > store these credentials in the cloud.cluster_details table. Similarly, > we also need to store the username/password required to login to a > Nexus 1000v virtual supervisor module, and we store that password in > the cloud.virtual_supervisor_module table. > > Currently, these passwords are stored in clear text, which is not > desirable. > > Since we need to be able to reconstruct/retrieve the password within > the management server, we cannot simply store the hash(salt + password) > in the database. We can do that only when the user provides the > password each time, so that we can check the hash of the salt (which we > should be generating separately for each password to make rainbow > attacks tougher) + password against the hash stored in the tables. > > It looks like there are two ways to go about implementing a solution - > encryption, or secret sharing. > > If we encrypt the password using a key (that is probably best > autogenerated like a salt), we can use that key to decrypt the password > each time we need to use that password to login to the Nexus VSM or > vCenter. But, storing that key in the same database where the encrypted > passwords reside would defeat the purpose of encryption. So, how best > to store these encryption keys for passwords? Does it help to store > them in a separate schema? Or a totally different database on some > other server and make it an option to the mgmt server installer to > create this new db on a new server? And where do we store the > credentials to login to that db server?? How do databases get stolen in > the first place? What can anyone do if the db root password is > compromised? > > Is there a concept of a "hidden table" in MySQL? Something that can > only be viewed by some one privileged user or role and nobody else, and > never gets exported by standard export tools? Even if such an option > exists, it probably still won't help since we cannot afford to lose > encryption keys during db migration. I'm just thinking aloud here. > > The second option, generating secret shares from passwords, relies on > hiding the algorithm that we use to generate secret shares from some > data. Since cloudstack code is opensource, two ways we could make this > secure would be 1) to have a (n, n) secret key generation scheme, so > that all n shares are required to reconstruct the password, and we > store n-1 shares on the db, and store the 1 remaining share somewhere > really secure. Unfortunately this again boils down to an encryption key > model. In our case we could have n=2. 2) to allow the customer to > plugin her own secret share generation algorithm, but I feel that in > itself could be a potential security risk, unless we sandbox it in some > robust way. > > It would be great if you could provide your views. This problem looks > byzantine and I don't know if it has a simple/elegant solution. > > > Regards, > Vijay
Vijay, CloudStack already has DB encryption support. To encrypt column in a table add encryptable=true attribute to the corresponding VO. For example, see password column in core/src/com/cloud/network/VpnUserVO.java. "About Password and Key Encryption" section in install guide [1] has more info. Please let me know if you have further questions. Regards, Kishan [1] http://download.cloud.com/releases/3.0.0/CloudStack3.0InstallGuide.pdf
