There is logic that creates a public key before you make connection call to the mobile server. It uses ‘DiffielHellman.createPublicKey()’ then it gets passed to the method ‘setServerPublicKey’.
I have a 2-part question… Can I set this public key without using the ‘createPublicKey’ method? And if I set it myself, can I use the DiffielHellman’s ‘encodeString’ method to encrypt my credentials?
I would do this, so I could save the encrypted credentials in a config file. When the app loads I would pass the creds straight into the ‘login’ method.
Is this the intended route that Milestone recommends or should I look at this differently?
You guys have very helpful, I appreciate that!
Thanks,
Mike
Hi Mike,
In short answer will be no, unfortunately.
In details when we look into Diffie-Hellman key exchange algorithm (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) we see that for every exchange between A and B there are 4 keys in use - privateA, publicA, privateB and publicB. Based on it’s own private key and others public key every side calculates common shared private key, which is used by encryption/decryption.
(privateA & publicB generate cspk1 and privateB & publicA generate cpsk2, where cpsk1 == cpsk2)
As mobile server always changes its public/private key pair, generated cspk will be always different and as result mobile server won’t be able to decrypt correctly already saved user credentials.
What could be tried instead is credentials to be encrypted and decrypted directly with “CryptoJS.AES.encrypt” and “CryptoJS.AES.decrypt” calls using fixed (predefined) key.
Your workflow could be:
- User inputs credentials.
- Credentials are encrypted with fixed key and stored somewhere.
- Connect and Login via SDK in standard way.
- Disconnect.
- When new connect request arrives (user action/input) credentials are retrieved from the store and are decrypted (with same fixed key).
- Connect and Login via SDK in standard way.
- And so on.
This however will only make credentials not human readable but won’t make your integration secure.
As far as I know there is no secured store place in the web word (neither “Local Storage”, nor the “Session Storage”, nor the “Cookies”).
Milestone in general doesn’t recommend credential storage in the web integrations. For that reason it is not implemented in the XProtect Web Client itself.