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
