Hi Maninda, Same issue will be occur, if we forcefully expire the symmetric key, since it will also lead to huge migration effort.
On Mon, Nov 23, 2015 at 1:52 PM, Maninda Edirisooriya <[email protected]> wrote: > Hi Indunil, > > It seems the very first generated symmetric key is used forever throughout > the cluster until all the nodes go down and restart again. (and even after > whole cluster restart, according to the Prabath's suggestion of keeping the > key in file system) So until that happens is there any way to expire the > symmetric keys after they are used for encrypting certain amount of data or > after certain period of time? Otherwise the that may weaken the security of > encryptions if used for encrypting a lot of data. > > Thanks. > > > *Maninda Edirisooriya* > Senior Software Engineer > > *WSO2, Inc.*lean.enterprise.middleware. > > *Blog* : http://maninda.blogspot.com/ > *E-mail* : [email protected] > *Skype* : @manindae > *Twitter* : @maninda > > On Fri, Nov 20, 2015 at 2:49 PM, Indunil Upeksha Rathnayake < > [email protected]> wrote: > >> Hi all, >> >> Currently in Identity Server, *asymmetric encryption* is using as the >> data encryption mechanism. Following issues has been occurred due to the >> current implementation: >> >> 1) *Huge migration effort when Asymmetric key get expired* >> >> Currently we have a migration script for this. What it does is, we give >> the list of registry paths that contain encrypted data, old key and new key >> and the tool will decrypt using the old key and encrypt using the new key >> and restore it. Issue with this approach is that it is not a scalable >> solution because different products store data in different locations. We >> have to maintain an exhaustive list of all of those places. Also the tool >> is not future proof. When a new path is used to store encrypted data the >> tool needs to be updated. >> >> 2) *The data length that can be encrypted is limited* >> >> With asymmetric key encryption the data length that can be encrypted is >> limited by the private key length. >> >> *Following approach is suggested to overcome those issues: * >> *Use a symmetric key to encrypt the data and use an asymmetric key to >> encrypt that symmetric key.* >> As per the suggested approach, in server startup, a symmetric key will be >> generated. And that symmetric key will be encrypted using an asymmetric key >> and will be stored either in registry or in file system. Apart from that, >> the non encrypted symmetric key will be stored in own memory. >> >> >> >> Following scenarios has been considered in *IS cluster/ Muti-product >> cluster setup*. In there, issues can be occurred, if trying to write to >> the registry concurrently. >> In cluster startup, all the nodes will try to generate a symmetric key >> and store that key in registry as well as in their own memory. If the nodes >> in the cluster are trying to write to the registry concurrently, some nodes >> will be referring to invalid symmetric key and conflicts will be occurred >> when decrypting by using the valid key in the registry. >> >> *As a solution for this, we are trying to go for following approach:* >> *Before the very first encryption or decryption by any node, it will >> compare the key it has generated(which is stored in memory) with the key in >> the registry.* If the key is not matching, current key in it's memory >> will be changed to the key which is in the registry. So that every node in >> the cluster will be referring to the valid symmetric key(key stored in the >> registry) for encrypting any data. >> >> >> >> Really appreciate any feedbacks and ideas on this approach. It also goes >> without saying, any component doing encryption or decryption will wait for >> the carbon.core bundle to get activated which contains the CryptoUtil class >> which performs encryption and decryption. By the time carbon.core is >> activated we can guarantee the the symmetric key has been written to >> registry. >> >> Also this will be a change in carbon-kernel. >> @Kernel Team, we are hoping to do this change in a backward compatible >> manner. Do you see any reason for this not to be added to kernel-4.4.3 ? >> >> Thanks and Regards >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
