JSPatch Deployment Security Strategy
You are facing two security issues for using JSPatch:
- Transmission Security: JS script can call any Objective-C method, its privilege is quite powerful. If a third party changes the code, it leads to very bad consequences.
- Execution Security: Pushing a JS script has a very low cost, it actually means a small update to clients. If tests are insufficient, it might result some stability issues. The following article is to address these two issues.
If we want to protect our code from third party attacks, the easiest approach is to encrypt the code. We can apply zip encrypted compression, or AES encryption algorithm. While, this solution is simple, it has low security level, and can be cracked easily. Since the key has to store in the client, the key will be found by decompiling the client. There are some modified solutions:
- You can save the key in the keychain. It is also unreliable. The hacker can use jail-breaked device and use hook approach to get the key stored in the keychain.
- Push distinct keys to clients. This is way too complicated. You have to protect keys from the server, and the sever has to encrypt the script with different keys.
The solution above is not secure enough for us, and the complexity increases dramatically with same improvement of security.
Second solution is just using HTTPS transmission directly. It has high security. It cannot be decrypted unless the certificate on server side has been cracked. However, its advantage is complicated deployment. Users has to set up their servers to support HTTPS. Client sides has to do authentication of HTTPS. If authentication is missing, it loses security. For further details, checkout out this document. If severs have already supported HTTPS, it will be valid choice.
Is there a easy but promising solution? Here is the RSA validation.
This approach is digital signature. It uses similar asymmetric encryption like HTTPS.
- Server calculates the MD5 value of the script, as its digital signature.
- Server uses private key to encrypt MD5 value.
- Send the script and encrypted MD5 to clients.
- Clients use local public key to decrypt the MD5.
- Clients calculate the MD5 value of received file.
- Compare the value from step 4 and 5, if they are the same, the validation is passed.
If the validation has been passed, it means the script is not changed by a third party. Since the third part has to use decrypt packets using the private key, the private key is saved on the sever. This process is secure, unless the private key is leaked.
This method use the same approach from HTTPS, but it is easy to deploy. If you do care about script content, you can apply additional symmetric encryption to the script. This approach has many advantages, and recommended. Now, JSPatch platform use this approach.
The last issue, the local client code has possibility to be cracked and changed. Do we need to secure it? This is not a serious security issue, since you need to get root privilege to do so. If you want to do something, try to use symmetric encryption and validate MD5 values at each steps above.
For larger apps, pushing JS script needs more attentions. It is possible to result app crash, if the script is buggy. We need some mechanism to avoid this situation. If it is possible, it can be divided into three stages: before, now, after.
For large apps, you cannot send the script to all users. You have to send to it to a fraction of users, then check if any crash happens. Then covers all users progressively. If possible, you can use factor like kind of devices, operating system, location to cover most situations by minimum number of users.
If anything happens after release, we need some monitoring mechanism, like crash rate monitoring. Often, it has been adopted by all apps. You can add other monitor element if you need.
The last is reverting script afterwards. For some unpredicted reasons, we suggest run JSPatch on booting, the modification is persistent during runtime. So, the reversion is suggested to put the server side, which servers push revision command to clients. It will stop running JSPatch on the next booting.
However, the assumption above is based on client can receive the command properly, if the script made App crash on booting, this revision command will not be received. So it is better to have another layer of preventing booting crash.
The Beta Release and Monitoring can be ignored for small-scale apps. The reverting mechanics is recommended for all apps. Currently, JSPatch Platform also use above reverting solution.