incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Bhamidipati <vijayendra.bhamidip...@citrix.com>
Subject RE: Query regarding where to store encryption keys
Date Wed, 20 Jun 2012 20:58:58 GMT
-----Original Message-----
From: Kishan Kavala [mailto:Kishan.Kavala@citrix.com] 
Sent: Wednesday, June 20, 2012 12:32 PM
To: 'cloudstack-dev@incubator.apache.org'
Cc: Kelven Yang; Sateesh Chodapuneedi; Devdeep Singh
Subject: RE: Query regarding where to store encryption keys

> -----Original Message-----
> From: Vijayendra Bhamidipati 
> [mailto:vijayendra.bhamidipati@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



> Thanks Kishan! I'll look into this and ping you in case I have any questions.
Regards,
Vijay

Mime
View raw message