Secure data transfer security for Android apps

Android software typically communicates with the server using a WiFi network. WiFi is not always reliable, for example, an open network or a weak encrypted network, the user can listen to network traffic, the attacker may set up their own wifi phishing. In addition, you can also listen for network data in the Android system after root access.

Transmit sensitive data in plaintext without encryption

The most dangerous thing is to log in to your account or exchange data directly using the HTTP protocol. For example, an attacker can configure a DNS server on a phishing network that is set up, resolve the server domain name that the software is connecting to, and the server will be able to obtain user login information or act as an intermediary between the client and the original server to forward both data.

Early on, the login sessions of the Android clients of some of the well-known foreign social sites were not encrypted, and later the hacker tool Faceniff, which specifically sniffed the sessions and hijacked them (it even supported attacks on WEP, WPA, WPA2 encrypted WiFi networks), This is the only case I know of publicly attacking a mobile software vulnerability.

The solution to this type of problem is clearly-----the use of SSL/TLS-based HTTPS for sensitive data transmission.

SSL communication does not check certificate validity

In SSL/TLS communication, the client determines whether the server is trustworthy through a digital certificate and encrypts the communication with the server using the certificate's public key.

However, developers in the development process in order to resolve the problem of SSL certificate ( after using their own generated certificates, the client found that the certificate can not be formed with the system trusted root CA form a chain of trust, there are certificateexception and other exceptions ), The way that all certificates in the client are trusted in client code:

1      Public StaticHttpClient getwaphttpclient () {2   3               Try {4  5KeyStore Truststore =keystore.getinstance (Keystore.getdefaulttype ());6  7Truststore.load (NULL,NULL);8  9Sslsocketfactory SF =Newmysslsocketfactory (truststore);Ten   One Sf.sethostnameverifier (sslsocketfactory.allow_all_hostname_verifier); A   -                  　　 //all certificates in the phone, including third-party certificates installed by the user, are trusted here -   theHttpparams params =Newbasichttpparams (); -   - httpprotocolparams.setversion (params, httpversion.http_1_1); -   + Httpprotocolparams.setcontentcharset (params, HTTP. Utf_8); -   +Schemeregistry Registry =Newschemeregistry (); A   atRegistry.register (NewScheme ("http", Plainsocketfactory.getsocketfactory (), 80)); -   -Registry.register (NewScheme ("https", SF, 443)); -   -Clientconnectionmanager CCM =NewThreadsafeclientconnmanager (params, registry); -   in                      return Newdefaulthttpclient (CCM, params); -   to}Catch(Exception e) { +   -                      return Newdefaulthttpclient (); the   *               } $  Panax Notoginseng}

Instead of overwriting the default Google certificate checking mechanism (X509trustmanager) in the client, there is no validation-related code for the SSL certificate in the code:

1  Public classMysslsocketfactoryextendsSslsocketfactory {2  3Sslcontext Sslcontext =sslcontext.getinstance ("TLS");4  5         PublicMysslsocketfactory (KeyStore Truststore)throwsnosuchalgorithmexception, Keymanagementexception, Keystoreexception, unrecoverablekeyexception {6  7               Super(Truststore);8  9TrustManager TM =NewX509trustmanager () {Ten   One                        Public voidCheckclienttrusted (x509certificate[] chain, String authtype)throwscertificateexception { A   -                      } -   the                     //The client has not verified the validity of the SSL certificate, and has used a custom method to override the Android's own checksum method -   -                       Public voidCheckservertrusted (x509certificate[] chain, String authtype)throwscertificateexception { -   +                      } -   +                       Publicx509certificate[] Getacceptedissuers () { A   at                             return NULL; -   -                      } -   -               }; -   inSslcontext.init (NULL,NewTrustmanager[] {TM},NULL); -   to        }  +}

If a malicious certificate is installed on a user's phone, the user's communication can be tapped through a man-in-the-middle attack and the data in the request or response is modified.

In a phishing WiFi network, similarly, an attacker could set up a DNS server to enable clients to communicate with a specified server. The attacker deploys another certificate on the server, and during the session establishment phase, the client receives the certificate, and if the client ignores the exception on the certificate or accepts the certificate, it will successfully establish the session and begin encrypting communication. However, the attacker has a private key, so it can decrypt the plaintext of the data sent by the client. An attacker can also impersonate a client, contact a real server, and act as a middleman for listening.

Mobile app man-in-the-middle attack process:

1 When the client starts, it requires a handshake between the client and the server before transmitting the data, and during the handshake, the password information of the two parties to encrypt the transmitted data will be established.

2 in this process, when the client requests the server's handshake information is intercepted, the impersonated client requests the server (sending a set of cryptographic rules that it supports to the server), and the server selects a set of cryptographic algorithms and hash algorithms, and sends its own identity information back to the client as a certificate. The certificate contains information such as the website address, the encrypted public key, and the issuing authority of the certificate.

3 in this case, the middleman intercepts the certificate information returned to the client from the server and replaces it with its own certificate information.

4 after the client obtains the response of the middleman, it chooses to encrypt the data transmission with the intermediary's certificate.

5 The intermediary is decrypted with its own certificate after obtaining the client's request data.

6 after eavesdropping or modifying the request data, then impersonate the client encrypted request data to the server. This completes the process of the entire man-in-the-middle attack.

Protection method:

It is possible to use CA agencies to issue certificates, but if combined with the actual situation, time and cost are too high, it is seldom useful to do so at present. Because the mobile application server is actually fixed, the certificate is also fixed, you can use the "certificate or Public Key locking" method to protect the validity of the certificate is not verified issues.

Specific implementation:

1 Public Key lock

The certificate public key is written to the client apk, and HTTPS communication checks that the certificate public key is consistent with the APK (implementing the X509trustmanager Interface)when the server is transmitting.

1  Public Final classPubkeymanagerImplementsx509trustmanager{2     Private StaticString Pub_key = "30820122300d06092a864886f70d0101" + " 0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85 "+" 5A545B1F0CC8AFB19E38213BAC4D55C3F2F19DF6DEE82EAD67F70A990131B6BC "+" ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657 "+" 2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8 "+" 609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50 "+" C6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00 "+" 33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38 "+" cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b "+" e0b7a5bc860966dc84f10d723ce7eed5430203010001 ";3  4     //Lock the certificate public key in APK5  6      Public voidCheckservertrusted (x509certificate[] chain, String authtype)throwscertificateexception7      8     {9      Ten         if(Chain = =NULL) { One           A             Throw NewIllegalArgumentException ("checkservertrusted:x509certificate array is null"); -           -         } the           -         if(! (Chain.length > 0)) { -           -             Throw NewIllegalArgumentException ("Checkservertrusted:x509certificate is empty"); +           -         } +           A         if(! (NULL! = AuthType && authtype.equalsignorecase ("RSA"))) { at           -             Throw NewCertificateexception ("Checkservertrusted:authtype is not RSA"); -           -         } -           -         //Perform Customary SSL/TLS checks in           -         Try { to           +Trustmanagerfactory TMF = trustmanagerfactory.getinstance ("X509"); -           theTmf.init ((KeyStore)NULL); *           $              for(TrustManager trustManager:tmf.getTrustManagers ()) {Panax Notoginseng               - ((X509trustmanager) trustmanager). checkservertrusted (chain, authtype); the               +             } A           the}Catch(Exception e) { +           -             Throw Newcertificateexception (e); $           $         } -           -         //Hack Ahead:biginteger and ToString (). We know a DER encoded public Key begins the           -         //with 0x30 (ASN.1 SEQUENCE and constructed), so there are no leading 0x00 to drop.Wuyi           theRsapublickey PubKey = (rsapublickey) chain[0].getpublickey (); -           WuString encoded =NewBigInteger (1/*Positive*/, pubkey.getencoded ()). ToString (16); -           About         //Pin It! $           -         Final Booleanexpected =pub_key.equalsignorecase (encoded); -           -         if(!expected) { A           +             Throw NewCertificateexception ("checkservertrusted:expected public key:" + Pub_key + ", got public key:" +encoded); the           -         } $       the     } the   the}

2 Certificate lockout:

That is, the issuing of public key certificates for the client is stored in the mobile client (using KeyStore), when HTTPS communication, in the client code to secure the certificate information, not from the server to obtain .

For certificates or public key locking techniques, refer to the following links:

Https://www.owasp. org/index.php/certificate_and_public_key_pinning

Secure data transfer security for Android apps