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.

The most dangerous way to transmit sensitive data unencrypted plaintext is to log in to the 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 uses the certificate's public key to encrypt the communication with the server. 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 3Try { 4 5 KeyStore Truststore =keystore.getinstance (Keystore.getdefaulttype ());6 7 Truststore.load (NULL,NULL); 8 9 Sslsocketfactory SF =Newmysslsocketfactory (truststore);10 11Sf.sethostnameverifier (sslsocketfactory.allow_all_hostname_verifier);12 13//all certificates in the phone, including third-party certificates installed by the user, are trusted hereHttpparams params =Newbasichttpparams ();16 17httpprotocolparams.setversion (params, httpversion.http_1_1);18 19Httpprotocolparams.setcontentcharset (params, HTTP. Utf_8);Schemeregistry Registry =Newschemeregistry ();Registry.register (NewScheme ("http", Plainsocketfactory.getsocketfactory (), 80));Registry.register (NewScheme ("https", SF, 443));Clientconnectionmanager CCM =NewThreadsafeclientconnmanager (params, registry);28 29return Newdefaulthttpclient (CCM, params);30 31}Catch(Exception e) {32 33return Newdefaulthttpclient ();34 35               }36 37}

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 3 Sslcontext Sslcontext =sslcontext.getinstance ("TLS");4 5 PublicMysslsocketfactory (KeyStore Truststore)throwsnosuchalgorithmexception, Keymanagementexception, Keystoreexception, unrecoverablekeyexception {6 7Super(Truststore);8 9 TrustManager TM =NewX509trustmanager () {10 11 Public voidCheckclienttrusted (x509certificate[] chain, String authtype)throwscertificateexception {12 13                      }14 15//The client has not verified the validity of the SSL certificate, and has used a custom method to override the Android's own checksum method16 17 Public voidCheckservertrusted (x509certificate[] chain, String authtype)throwscertificateexception {18 19                      }20 21 Publicx509certificate[] Getacceptedissuers () {22 23return NULL;24 25                      }26 27               };Sslcontext.init (NULL,NewTrustmanager[] {TM},NULL);30 31        } 32}

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 the password information of the two sides encrypted transmission data is established during the handshake. 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. Protective measures: The use of CA institutions to issue certificates is feasible, but if combined with the actual situation, time and cost is too high, so 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. Implementation: 1 Public Key lock writes the certificate public key to the client apk, and HTTPS communicates when the certificate public key is consistent with the APK (implementing the X509trustmanager Interface) when the service side is transmitted.

1 Public Final classPubkeymanagerImplementsx509trustmanager{2Private 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 10if(Chain = =NULL) {11 12Throw NewIllegalArgumentException ("checkservertrusted:x509certificate array is null");13 14         }15 16if(! (Chain.length > 0)) {17 18Throw NewIllegalArgumentException ("Checkservertrusted:x509certificate is empty");19 20         }21 22if(! (NULL! = AuthType && authtype.equalsignorecase ("RSA"))) {23 24Throw NewCertificateexception ("Checkservertrusted:authtype is not RSA");25 26         }27 28//Perform Customary SSL/TLS checks29 30Try {Trustmanagerfactory TMF = trustmanagerfactory.getinstance ("X509");Tmf.init (KeyStore)NULL);35 36 for(TrustManager trustManager:tmf.getTrustManagers ()) {37 38((X509trustmanager) trustmanager). checkservertrusted (chain, authtype);39 40             }41 42}Catch(Exception e) {43 44Throw Newcertificateexception (e);45 46         }47 48//Hack Ahead:biginteger and ToString (). We know a DER encoded public Key begins49 50//with 0x30 (ASN.1 SEQUENCE and constructed), so there are no leading 0x00 to drop.Wuyi Rsapublickey PubKey = (rsapublickey) chain[0].getpublickey ();Encoded String =NewBigInteger (1/*Positive*/, pubkey.getencoded ()). ToString (16);55 56//Pin It!57 58Final Booleanexpected =pub_key.equalsignorecase (encoded);59 60if(!expected) {61 62Throw NewCertificateexception ("checkservertrusted:expected public key:" + Pub_key + ", got public key:" +encoded);63 64         }65 66     }67 68}

2 Certificate Locking: 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 is not obtained from the server.

Secure data transfer security for Android apps