We also need to think about migration and deployment effort. - Existing users of 4.4.0, 4.4.1 & 4.4.2 based products will still need to use old encryption when migrating, unless the existing data is decrypted and encrypted again with the new key. - If this is added to 4.4.3, then deploying products that are based on 4.4.3 and previous kernel versions together will have issues since they use different encryption approach.
@Prabath, Johann, how can we address these concerns? On Mon, Nov 23, 2015 at 3:39 PM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > Hi Kishanthan, > > Yes. We are going to make sure the order at runtime by depending on OSGI > service references. There won't be any API changes, and will be > implemented in backward compatible manner. > > Thanks and Regards > > On Mon, Nov 23, 2015 at 2:57 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> >> >> On Fri, Nov 20, 2015 at 2:49 PM, Indunil Upeksha Rathnayake < >> indu...@wso2.com> 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 indu...@wso2.com >>> >> >> >> >> -- >> *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>* >> > > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email indu...@wso2.com > -- *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
