This should be implemented in a backward compatible manner.. 1. If one decides to go ahead with the current encryption mechanism they should be allowed to do that, even after upgrading to the latest version. 2. If one decides to go ahead with new one - with old data - then we need to provide a tool to migrate to the new encryption scheme. I think we already have done this at the time when people want to change their keys (thats a problem we have today even). 3. Any new deployment can use the new encryption scheme..
Thanks & regards, -Prabath On Mon, Nov 23, 2015 at 2:21 AM, Kishanthan Thangarajah <kishant...@wso2.com > wrote: > 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>* > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
