Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 vijayendra.bhamidipati@citrix.com designates 66.165.176.63 as permitted
 sender)
From: Vijayendra Bhamidipati <vijayendra.bhamidipati@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
CC: Kelven Yang <kelven.yang@citrix.com>, Sateesh Chodapuneedi
	<sateesh.chodapuneedi@citrix.com>, Devdeep Singh <devdeep.singh@citrix.com>
Date: Wed, 20 Jun 2012 13:58:58 -0700
Subject: RE: Query regarding where to store encryption keys
Thread-Topic: Query regarding where to store encryption keys
Thread-Index: Ac1PGSBgLkdZZTUFSYmIsF45wbCljwAAMpaQAANfBYA=
Message-ID: 
 <93099572B72EB341B81A644E134F240B012F6C8184D9@SJCPMAILBOX01.citrite.net>
References: 
 <93099572B72EB341B81A644E134F240B012F6CB7D428@SJCPMAILBOX01.citrite.net>
 <33740054EBF5B64BB213E2E0916F2C13EA107315CF@BANPMAILBOX01.citrite.net>
In-Reply-To: 
 <33740054EBF5B64BB213E2E0916F2C13EA107315CF@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

-----Original Message-----
From: Kishan Kavala [mailto:Kishan.Kavala@citrix.com]=20
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=20
> [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
>=20
> Hi Team,
>=20
> This is with reference to bug CS-15151=20
> (http://bugs.cloudstack.org/browse/CS-15151). I have some questions=20
> and it would be great if you could share your knowledge and suggestions.
>=20
> We have a need to store credentials required to login to vCenter, so=20
> that that cloudstack management server can log in and talk to it. We=20
> store these credentials in the cloud.cluster_details table. Similarly,=20
> we also need to store the username/password required to login to a=20
> Nexus 1000v virtual supervisor module, and we store that password in=20
> the cloud.virtual_supervisor_module table.
>=20
> Currently, these passwords are stored in clear text, which is not=20
> desirable.
>=20
> Since we need to be able to reconstruct/retrieve the password within=20
> the management server, we cannot simply store the hash(salt +=20
> password) in the database. We can do that only when the user provides=20
> the password each time, so that we can check the hash of the salt=20
> (which we should be generating separately for each password to make=20
> rainbow attacks tougher) + password against the hash stored in the tables=
.
>=20
> It looks like there are two ways to go about implementing a solution -=20
> encryption, or secret sharing.
>=20
> If we encrypt the password using a key (that is probably best=20
> autogenerated like a salt), we can use that key to decrypt the=20
> password each time we need to use that password to login to the Nexus=20
> VSM or vCenter. But, storing that key in the same database where the=20
> encrypted passwords reside would defeat the purpose of encryption. So,=20
> how best to store these encryption keys for passwords? Does it help to=20
> store them in a separate schema? Or a totally different database on=20
> some other server and make it an option to the mgmt server installer=20
> to create this new db on a new server? And where do we store the=20
> credentials to login to that db server?? How do databases get stolen=20
> in the first place? What can anyone do if the db root password is=20
> compromised?
>=20
> Is there a concept of a "hidden table" in MySQL? Something that can=20
> only be viewed by some one privileged user or role and nobody else,=20
> and never gets exported by standard export tools? Even if such an=20
> option exists, it probably still won't help since we cannot afford to=20
> lose encryption keys during db migration. I'm just thinking aloud here.
>=20
> The second option, generating secret shares from passwords, relies on=20
> hiding the algorithm that we use to generate secret shares from some=20
> data. Since cloudstack code is opensource, two ways we could make this=20
> secure would be 1) to have a (n, n) secret key generation scheme, so=20
> that all n shares are required to reconstruct the password, and we=20
> store n-1 shares on the db, and store the 1 remaining share somewhere=20
> really secure. Unfortunately this again boils down to an encryption=20
> key model. In our case we could have n=3D2.  2) to allow the customer to=
=20
> plugin her own secret share generation algorithm, but I feel that in=20
> itself could be a potential security risk, unless we sandbox it in=20
> some robust way.
>=20
> It would be great if you could provide your views. This problem looks=20
> byzantine and I don't know if it has a simple/elegant solution.
>=20
>=20
> Regards,
> Vijay

Vijay,
  CloudStack already has DB encryption support. To encrypt column in a tabl=
e add encryptable=3Dtrue attribute to the corresponding VO. For example, se=
e password column in core/src/com/cloud/network/VpnUserVO.java. "About Pass=
word 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 questi=
ons.
Regards,
Vijay