Android Application Security-Data Transmission Security

Android Application Security-Data Transmission Security
Android usually uses a Wi-Fi network to communicate with the server. Wi-Fi is not always reliable. For example, in an open or weak-encrypted network, the access provider can listen to network traffic. Attackers may set up WiFi phishing on their own. In addition, after obtaining the root permission, you can also listen to network data in the Android system. The most dangerous thing to transmit sensitive data in non-encrypted plain text is to log on to an account or exchange data directly using the HTTP protocol. For example, if an attacker configures a DNS server in a self-configured phishing network and resolves the Domain Name of the server to be connected by the software to another server, the server can obtain user logon information, or act as the intermediary between the client and the original server to forward data from both parties. In the early days, login sessions of Android clients on some well-known foreign social websites were not encrypted. Later, FaceNiff, a hacker tool, appeared, attackers can sniff and hijack these sessions (it even supports attacks on Wi-Fi networks encrypted by WEP, WPA, and WPA2 ), this is the only case I know about public attacks against mobile software vulnerabilities. The solution to this type of problem is obviously ----- transmission of sensitive data using SSL/TLS-based HTTPS. SSL communication does not check whether the certificate is valid in SSL/TLS communication. The client uses a digital certificate to determine whether the server is trusted, and uses the public key of the certificate to encrypt the communication with the server. However, in order to solve the problem of ssl Certificate Errors During Development (after using a self-generated certificate, the client finds that the certificate cannot form a trust chain with the Trusted Root CA of the system, exceptions such as CertificateException occur). All certificates in the trusted client are used in the client code: 1 public static HttpClient getWapHttpClient () {2 3 try {4 5 KeyStore trustStore = KeyStore. getInstance (KeyStore. getDefaultType (); 6 7 trustStore. load (null, null); 8 9 SSLSocketFactory sf = new MySSLSocketFactory (trustStore); 10 11 sf. setHostnameVerifier (SSLSocketFactory. ALLOW_ALL_H OSTNAME_VERIFIER); 12 13 // all certificates in the phone are trusted here, including third-party certificates installed by the user 14 15 HttpParams params = new BasicHttpParams (); 16 17 HttpProtocolParams. setVersion (params, HttpVersion. HTTP_1_1); 18 19 HttpProtocolParams. setContentCharset (params, HTTP. UTF_8); 20 21 SchemeRegistry registry = new SchemeRegistry (); 22 23 registry. register (new Scheme ("http", PlainSocketFactory. getSocketFactory (), 80); 24 25 registry. register (new Sche Me ("https", sf, 443); 26 27 ClientConnectionManager ccm = new ThreadSafeClientConnManager (params, registry); 28 29 return new DefaultHttpClient (ccm, params ); 30 31} catch (Exception e) {32 33 return new DefaultHttpClient (); 34 35} 36 37} and overwrite google's default certificate check mechanism (X509TrustManager) on the client ), there is no code in the code to verify the SSL certificate validity: 1 public class MySSLSocketFactory extends SSLSocketFactory {2 3 SSLContext sslContext = SSLCont Ext. getInstance ("TLS"); 4 5 public MySSLSocketFactory (KeyStore truststore) throws failed, failed, KeyStoreException, UnrecoverableKeyException {6 7 super (truststore); 8 9 TrustManager tm = new X509TrustManager () {10 11 public void checkClientTrusted (X509Certificate [] chain, String authType) throws CertificateException {12 13} 14 15 // the client does not verify the validity of the SSL Certificate and uses a custom party Method override android built-in verification method 16 17 public void checkServerTrusted (X509Certificate [] chain, String authType) throws CertificateException {18 19} 20 21 public X509Certificate [] getAcceptedIssuers () {22 23 return null; 24 25} 26 27}; 28 29 sslContext. init (null, new TrustManager [] {tm}, null); 30 31} 32} If a malicious certificate is installed on your mobile phone, then, the man-in-the-middle attack can be used to intercept user communication and modify the data in the request or response. In a phishing Wifi network, attackers can set up a DNS server to allow clients to communicate with the specified server. The attacker deploys another certificate on the server. During the session establishment phase, the client receives the certificate. If the client ignores the exception on the certificate or accepts the certificate, the session is successfully established and encrypted communication starts. However, attackers have private keys, so they can decrypt the plaintext data sent from the client. Attackers can also simulate the client to contact the Real Server and act as the intermediary for listening. Mobile app man-in-the-middle attack process: 1. When the client is started, a handshake is required between the client and the server before data transmission. During the handshake, the password information of both parties is encrypted. 2. In this process, the man-in-the-middle intercepts the handshake information of the client request server and simulates the client request to the server (send a set of encryption rules supported by him to the server ), the server selects a set of encryption algorithms and HASH algorithms, and sends the identity information to the client in the form of a certificate. The certificate contains the website address, the encrypted public key, and the certificate authority. 3. At this time, the man-in-the-middle will intercept the certificate information returned by the server to the client and replace it with your own certificate information. 4. After the client obtains the man-in-the-middle response, it will select the man-in-the-middle certificate for encrypted data transmission. 5. After obtaining the request data from the client, the man-in-the-middle decrypts the data with his own certificate. 6. After listening or modifying the request data, simulate the client to encrypt the request data and send it to the server. This completes the entire man-in-the-middle attack process. Protection Method: it is feasible to use a CA to issue certificates. However, if combined with the actual situation, the time and cost are too high, so this method is rarely used at present. Because the mobile app server is actually fixed, the certificate is also fixed. You can use the "Certificate or public key lock" method to protect the certificate validity from being verified. Implementation: 1. The public key is locked and the public key of the certificate is written to the client apk. During https communication, check whether the public key of the certificate is consistent with that in the apk (X509TrustManager interface is implemented ). 1 public final class PubKeyManager implements X509TrustManager {2 private static String PUB_KEY = "30820122300d06092a864886f70d0101" + "renew" 395b8 "+" certificate "+" certificate "; 3 4 // lock the certificate public Key in apk 5 6 public void checkServerTrusted (X509Certificate [] Chain, String authType) throws CertificateException 7 8 {9 10 if (chain = null) {11 12 throw new IllegalArgumentException ("checkServerTrusted: X509Certificate array is null "); 13 14} 15 16 if (! (Chain. length> 0) {17 18 throw new IllegalArgumentException ("checkServerTrusted: X509Certificate is empty"); 19 20} 21 22 if (! (Null! = AuthType & authType. repeated signorecase ("RSA") {23 24 throw new CertificateException ("checkServerTrusted: AuthType is not RSA "); 25 26} 27 28 // Perform customary SSL/TLS checks29 30 try {31 32 TrustManagerFactory tmf = TrustManagerFactory. getInstance ("X509"); 33 34 tmf. init (KeyStore) null); 35 36 for (TrustManager trustManager: tmf. getTrustManagers () {37 38 (X509TrustManager) trustManager ). chec KServerTrusted (chain, authType); 39 40} 41 42} catch (Exception e) {43 44 throw new CertificateException (e); 45 46} 47 48 // Hack ahead: bigInteger and toString (). we know a DER encoded Public Key begins49 50 // with 0 × 30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0 × 00 to drop.51 52 RSAPublicKey pubkey = (RSAPublicKey) chain [0]. getPublicKey (); 53 54 String encoded = new BigInteger (1 /* Positive */, pubkey. getEncoded (). toString (16); 55 56 // Pin it! 57 58 final boolean expected = pub_key.w.signorecase (encoded); 59 60 if (! Expected) {61 62 throw new CertificateException ("checkServerTrusted: Expected public key:" + PUB_KEY + ", got public key:" + encoded ); 63 64} 65 66} 67 68} 2 certificate locked: the client is issued with a public key certificate stored in the mobile client (using keystore). During https communication, in the client code, the certificate information is fixed, not obtained from the server.