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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
