Home  >  Q&A  >  body text

ios - 服务器想移动客户端传输数据的安全问题

最近在思考安全性的问题。情景是:服务器和客户端之间的数据通讯(更确切的是,主要是服务器给客户端传递数据)。
如果使用https的话,不可避免的是每次链接都会有更多的握手步骤,带来的时间开销,会大大的降低移动端的用户体验吧。而且,用经典的ASIHttprequest似乎也不支持https╮(╯_╰)╭。

不知道大侠们有些什么更好的建议?

PHP中文网PHP中文网2766 days ago462

reply all(4)I'll reply

  • PHP中文网

    PHP中文网2017-04-17 11:22:57

    The symmetric encryption method mentioned by @gaosboy is basically feasible. To enhance security, another simple solution is provided:

    1. The server and the client first agree on a key K, and the client can encrypt and store K through tools such as SFHKeychainUtils;
    2. When encrypting on the server side, you can get the current unix timestamp. Assuming it is T, you can use K-md5(T)-K (or any other rule, as long as T is confused into the key) during the encryption process. As the key, encrypt and pass the encryption timestamp T or md5(T) to the client;
    3. After the client splices the key according to the corresponding rules, it decrypts it.

    The advantage of this is that even if the key K or the key in any session is cracked, all sessions still cannot be completely decrypted. You must know K, the key splicing rules and the encryption method at the same time to completely crack .

    reply
    0
  • 巴扎黑

    巴扎黑2017-04-17 11:22:57

    I feel @yuanlizbyy’s solution is not reliable enough. The code and key are all on the client, so it's not difficult for those who really want to crack it. LZ thinks that the https handshake is too long-winded, so you can implement one yourself. It is much simpler. You only need to use a pair of public and private keys of RSA (or other asymmetric encryption systems). The client holds the public key and the server holds the private key.

    Connection process:

    1. The client generates a random key K (of course K needs to be strong enough), encrypts it with the public key, and then sends it to the server
    2. The server uses the private key to decrypt and obtain K
    3. The two directly use AES (key is K) to encrypt communication.

    Advantages: safe (unless the server is invaded to obtain the private key, or the time-tested RSA/AES algorithm is cracked), fast (only the first round trip requires slightly slower RSA decryption).
    Disadvantages: A handshake is required (but it can be solved: the round-trip handshake can actually be encrypted with the key K to send additional data).

    Welcome to buy bricks.

    reply
    0
  • 怪我咯

    怪我咯2017-04-17 11:22:57

    I used to use symmetric encryption.
    AES, the client maintains a private key, encrypts the data that needs to be encrypted and transmits it to the server through http, and then decrypts it

    reply
    0
  • 怪我咯

    怪我咯2017-04-17 11:22:57

    @felix021’s solution is more reliable than @yuanlizbyy’s

    reply
    0
  • Cancelreply