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. > How are we going to make sure the above order at runtime? Are you going to depend on some OSGi service references? > > 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 ? > Are there going to be new API additions? > > Thanks and Regards > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email [email protected] > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
