I want to establish an ssl communication to the server from my android client.
this is what I've done so far:
1 Created a a pair of public private keys using java keytool genkey(and in the process created a self signed certificate)
2. Exported the public key and imported the public key in to another keystore(called customkeystore)
Now I want to use this customkeystore file as my truststore. Where should I place this file in my android client and how to make it aware of the path of this trustore and access it.
Don't know Android but I would imagine that you just load your keystore like in any Java application.
This is what happens here SSL through Android and here SSL Verification Android
Related
I have already built a server app and an android app. So far they were communicating over http, but I am sending sensitive information in each request (like JWT). Therefore I neet to use Https instead.
I have generated a p12 certificate.
On the server side:
I've copied the certificate to resources/keystore/sampleName.p12
I've added these lines to my application.properties
server.ssl.key-store-type=PKCS12
server.ssl.key-store-password=samplePassword
server.ssl.key-store=classpath:keystore/sampleName.p12
server.ssl.key-alias=sampleName
On android side I use okHttp and create the client like this
val httpClient = OkHttpClient.Builder()
.certificatePinner(
CertificatePinner.Builder()
.add(
https://10.0.2.2:8080,
"sha256/lVIcG+gpmlabsq1bW5RbvB+kqVSHKdOFyoxjo9+SLEs="
).build()
)
.build()
I use https://10.0.2.2:8080 because I run the server app only localy and I also run the android app on an emulator on the same laptop.
To get sha256/lVIcG+gpmlabsq1bW5RbvB+kqVSHKdOFyoxjo9+SLEs= I've used keytool -list -v -keystore sampleName.p12 -storetype PKCS12 -storepass samplePassword and converted the sha256 fingerprint which was in hex to base64.
Now when I try to send any request to the server I get an
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found
I am clearly missing something but I dont know what. Is there anything else I need to do? Or did I do something wrong? Or is it just not supposed to work localy?
Note that this is just an exercise for me and I won't be actually deploying the server app on any real server and I won't release the android app.
But still I will be presenting the solution and I really nedd it to be solid and work localy.
CertificatePinning is in addition to the normal certificate checks. It only further restricts the choice of certificate, since be default you will accept any cert for your host.
See Adding a custom certificate to an OkHttp Client for an existing answer.
Or read up here
https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/recipes/CustomTrust.java
https://square.github.io/okhttp/4.x/okhttp/okhttp3/-certificate-pinner/
I'm new to reverse engineering, I've never developed an android application before and I'm trying to extract from an android application the certificate it's using to authenticate to the server.
One of the answers to this post mentions that extracting a private key from an apk file is indeed a possible thing.
This post says that unlesss we have the original keystore file of the application we won't be able to extract the private key. Is it possible to get the original keystore file? Most of the posts seem to agree on the fact that this is impossible!
I've decompiled the application I'm interested in, and I retrieved the CERT.RSA from it, but I don't know if this can help me extract the certificate and the private key from the application. What can we do with the CERT.RSA file anyways?
I know that an android application is accessible to anyone from the google play store, so if what I'm trying to do is possible anyone could extract the certificate and private key and hack any application, but I just want to know if there were some specific tips/hacks, a good tutorial or just an indication of where to start off?
Here is the pcap I get when I send a request to the server that the app communicates with:
10.0.0.1 is the client IP address and 192.168.10.211 is the server's IP address, and we can see that the client is sending 2 certificates to the server during the handshake session, so where do these certificates come from? are they hardcoded in the application?
UPDATE
As you can see on the pcap file, the client does send a certificate to the server during the handshake session, so I spent the last few days trying to retrieve it and use it to forward a request to my server.
I've finally managed to retrieve the certificate, the problem is I don't know how can I use it to get the job done.
Here is exactly what I did:
This is the java code that logs the certificate and the password that the client uses during the handshake protocol:
public static native byte[] getCplusPKCS12Cert();
public static native byte[] getCplusPKCS12Pass();
static {
System.loadLibrary("cplusnative");
}
public static SSLSocketFactory a() {
SSLSocketFactory sSLSocketFactory = null;
SSLContext instance = SSLContext.getInstance("TLS");
byte[] cplusPKCS12Cert = getCplusPKCS12Cert();
String s = Base64.getEncoder().encodeToString(cplusPKCS12Cert);
Log.d('certificate',s);
byte[] cplusPKCS12Pass = getCplusPKCS12Pass();
Log.d('password',cplusPKCS12Pass);
return sSLSocketFactory;
}
This allows me to get the certificate which is a PKCS12 certificate that's secured with a password which is logged to the terminal too when I launch:$ adb logcat
This is what I get:
certificate:
MIIQuQIBAzCCEH8GCSqGSIb3DQEHAaCCEHAEghBsMIIQaDCCCx8GCSqGSIb3DQEHBqCCCxAwggsM
AgEAMIILBQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQYwDgQIYreCShA7AXACAggAgIIK2G6f/joD
/1VqmZGehnd4f6UQ89fDrRUJ1tugG3ncL6ewz8iD/viVbdDtYD2+CYQaXAu2jx4ePRw9ohippdK3
pQLPPDzjzN7p4RmmsdCc3F8lVEmVkDq2IRzB1BSmZ3HK6PU5v5BvUQmIqZpijUiLCLdn7dKNTyvj
FFKDfGS0oy5JVYr+O5WS1CqxfafDtwrX+iCiHMzDulGYVldb9+FHV8SMKkiiwjszih3+hgo+S6DV
a3Cyfir3KEa9G2MBh2VkeQgCQdw893WAyFbIwHdB9QWWkwSWk4FGCtXP4gZ0Vjprv0tRydxnAcxp
ish5b5vmG0uMtguRC2criPAyFhW1NlT2TqzlX/mJW+shdh2FRvSyGlWqzcPdcT8Uks8BnZHpYOZV
P9LbYVnO0X7bEAnNw6lsmbL4jxPJhAXGXX16vaXcCWLF+s64qFG6j/Jp61Vf6MxJWiqaC2AWLIVf
dh9FJjQlvKtoX04uK9abYdBEvJ/J3u+/YIO7EIPiVwet1C23PRahybAQuGIXXHkk23rSDQ2AaIwn
NBCBmW+mv2RuraS5KOm7Lk/9a9jWEWbjTYIMYSiy0PUFjhiZjjf3F1E4OqHGhbmCn3uhiYBGUXLR
D8D33R9kMpzg1CAKq5ZOOyMkcNy2TWiWFB0ykQNuaPoOaoiXtsJiGEM/9ejhFQzOB28GiE3DG7xR
fOb/BQTgjPzzAtfs1yXalzWu9CgguVZ/7/wL9sQVO29BWYwZQvbizEGczmPcHnzK4ft81bK1Ap4j
ZDvqSEfOBbH6j2BNw1d9hPUF/kjaccm/2jKkJTG4zQSz7RzxNs3w+QrYryc5sx8sQgcnYyGemiri
zHoNahbQU9RIzjP3lE0IjTuYl//DVXlVMXMu6JuLGwlC1F5wZ108NH1gUBC/Hepz8PXbwqB+exuS
ouhOeub+MEHXNIaUoBpwaH+68ezDh7EAId9ytZXkiDWO9XMJYvfDIcJHoAKSjEYpnMjr3C9FbUpM
Dm4Bzu2eDOPR5B9T3oXH+HUDlSn6wERxNd79FgWuyUljZ2kQXIPLlKEgcCulAszHQeLEYgh/vbnw
j/4lZ+LNehI6qyAphfEr1WOSfbVVGrZe0ekUDHi0hEifYm3sVwoiJHDE4Z0Qa+xHmGohVPrlvELN
hcG7K1+Hd+MuNgTNAwxj40ix3qGQKEDfXbUXJXbCPu3uLpkFTTWLj9WZKVKM2nvcACi5KpIfuyg2
6HJzRkDB7n58ZFZSm717pVudrKEyCh02d0AZcDGFUzEZdRmr8XYjCcZHh17Q0pBjMSKQ9W99fP/D
sOhX3rLSvx4Z7ox53CuPKGBPONE3wseL7LlPcGoo68yeBt8gCwDkwwe/crSyIQalL+a6XSmo5/TG
YV9baF7pdUpR5OujJfX9b2aDgrUxu/SYEunXUmiX8od2YRR465V5b0o9IdFGh3yY/BVpITnv+mAT
p0n29eLvrGv0POl3bIttY7cScvPVus9ETfQ6abqAL8DFadCh6RxenNZl+/sDsY1tQ0crW080kP1f
5l1Rx5M7uzojYRLLAbwecM7s07oXjHdqEFd8cc81SuwlMIYQ3nA/k2eUXcozGZmrVpkXcDm9RExk
/yFxKYVW5hoQUjseLtit3NoyJrIiK4+iC7WVWnQi2lsCdniXleEOLktb4an3wUzYVlFwhlTVsZgT
y9xZ5uQx4KSV56iOf99kcm1LJrbLwyfhTYfmESYqATcgcIxi7TzhFbxNKH5G/8laWmXufgnEwWqR
AtFdAJUYNhYPC3uVwxyiEt27H03PbVnc/KPtjPKd/NDQTM9wsDQR/UKD/bKZxsCU9H/xbPz6TVNJ
PswN7CCo+lwUMdDqaMSrRSo1alpN0oO6wMAjMMDwMCH5oQUBXWRXy2gyynfsBBjNYTAYb0EOliTy
9l7Lkwpb3ox+NfJpEsfbipfl0HHNx9S6Mq1hiNg1lu+TnCdmo17gxg3Jka7derx0NMOJdKBqUCQB
puJi1GAgZGnoM7PgFYCmwT65p1wc0BpzG66UMp460rGqpBYMhd+0Fynu/v4vJF7tU24qit3xvQBf
/ChRYjcOUU05YAy5ULNVo1EOpE+nucSsEkxJFcNfTcSoyTNkFgW5zsF8lAfo1PvS3dht7kIVComS
lk6c8H9yeLsgZDZ0NIiRTrGlWqI87hHyQzuG2Uc+mcDMRsr3E9dl/gDGaEOS8ati8IcXl0ngYdwU
8l6/RA0F3uKpDIwVa0nADtS/bZxqQAuEv6OJLsvqIctJKUsNHfYJ0yobPSEgn4JJE1RK27Z8gk+G
K6o7JryVF8rC8gB7e0jeBuC80buBAM+g8d3gjE2c2CivJV67pgiRZAT2U70uDScC++BGKgHwgulD
wXbktfxHTzQXnjwIgLChaMvcjNQ69xrPqu9d+sSU32FRSHGq6ArgI6IVJjY/m9SvnVy2oGawR2ir
7czyOdAz7eLNARInyfLL5mZNpUiD3gRc7hwVNgIh9M4q61Am4RwTJNaBVfu2bW6t6eGRBUFYwqEk
ML03oYwgzRObyIAvFcb3bPHzoZDmhZqgctTVCTiwUAr2sp7SqWsuccu2RL2jdWVKyvPD9kPxmn+Q
S+Q1yNJHpqhpktUvRmVVRJ75fcIoS5Y2r/KEK6X6azsplWzstG0eJk3yrx5i6KPs+nKhEHuOv4BN
CMEPIBR8oEz5bQ2RaLj9rqJAYlWLKp7pCcH055GFyIMc8ItbwFheVvcvJPbsWJ5eFlMQ+E16XhjA
cgKYpBfrlzgIUPu59JyygM/AJba3gd/BXk9Z38l/80M7IAncFlL3SaSfssjhUk53szTcioqNAs2a
fRTqExQiDYbeP8kvjLLBNmJ42F3v51hKwhLZvaZfdoDO8pwILigZYmUd5G357RQ2E6GgnrqfAl4Q
Ki6YMDfFtAAM4o1DpQXspDZnr9UJB/1xBTpxAdPimYpnHp+F30wqCvSupeDNSz0eQou3guZVeEYA
6wFKfa248swKCB9sfYDoGFN7l37mkjpSXaN1AMV1MWZ42JiVeSwVvqjuMw6dQqpBIwRbjgAknlGf
mp6ZmwSjty06ogDausrZ8YkmkMN3iPa9rHfo+iNXhty9F3BsQPB+sQkNOHtq50n0+7iuY9IQSzj6
c0EqwpS9qgvCwBXOCjvR9qpp4OUqLSu9SMGtFvjqDQRe1ohG+7EBaiYJHYhVYYHF55q/Ix7P/kTB
WVAHY70MY2j2KInt6vahSq0PS/WgtVzBAwXKv/nLNyU04avjsI9kZjUYC2K6Ob+rAStuQV5jbDvm
8kHNcQ4RWrdTPp3VMTl88/bJoO+/Z9F9cdKUykoNZj07MIgm51KTVPNCiV06EK44JUGOKerwkN1f
xPbvB4CmyNLwZy6UX4v0QHD2sREBjyfJzAtKfn3/k/Wuqqt8UWvf1WeAhvigiE2cz4ZAbUdojAUP
sD5irv/v5GZUTsYVHp5HQlqRRYpukFIwo7C5pEXRQyVomqYwggVBBgkqhkiG9w0BBwGgggUyBIIF
LjCCBSowggUmBgsqhkiG9w0BDAoBAqCCBO4wggTqMBwGCiqGSIb3DQEMAQMwDgQIYn82epgM5yEC
AggABIIEyP7HM+//zkp7+oOAjP8CbZGywV47hkOCQq33s9utRgSw3N+YwA5YJhB2m2q05Cgadgci
JEJqJZS4so/F8DNOSrB2ka0qDM5omK8YQ8vS+x+6GON+sXoXxvSpGXWfqywfDtkZGzBC6bX2CQTe
NpsHTCRemeVUeVtWjQJuPK0KmJkWvBg/RfYBjGJ1KnAxSoctVB7eaMsVHR6kdTlRdz6D2TVhEjIK
hk9VIUwBGBAOxpqDrO9dgDBJEADMgtnXsQQ/z5qeZg6nVReubq3/8nD2UvfWUqYYFfnC2fgVDE9w
GbhH/spFPLV/ue9ZNwTzzl+YQJMnrp+ihow1+Cv2uqxQdwXl0o4a06ENG6xN80IOQiS3u2OMNJVR
rkehXxYN4muWC3PRNxK8ZTkBe9Ljeccnh4IQzkLD+85fV7kiVKX14ipmFNXvhi2hhCntz1fe0pra
63Br9jV7GY2X1ZvLf7AlpNxye3epPOZ9Ns+Fd5cVIll1W6ZCluG2OeXN0Mcv28HsoTme7zVyeXkh
iQrtoni8E915JtLRYAZ3JO6bscsxZJzjdTTyqRlYN5BnmmfH1EJ8al6ReYoU/3iyjU/FjclFvhJo
8MrHTbKWG2YELgdPqBR6tcNMikTkobym8pvaURcu9PmA4zSU054vU17DaS1VWAkUjvhDQ7qEovL5
Xptt5uBkCYr6a2aqR/GYCl7iMxp3YsyKDGK/+qEHn9IX5vD7iMqomvcKqJiys+W3dsFDXbh7Q2jQ
R/hubPm0s6k/fI5AxELKT9SEjKOqi0dyhQRLXy6fzjuUtpkAOCKRPyerorbwLISN/mP32KhWWJVc
lTIflwW3B8Ii5J8XcLL728RFFObkXxD8SGEP4bab2LduzwlYBE+McFq1aYKfeL3Cy7buOYT4VElT
F2iSPLRfKHGh+8sxuDp7UBojOmMRWp6lnsR5Y14Prc6P24GtucderyRUC4Jot84xG1vqsZ0KMCE4
5Ld+oJypVdEG1d4k5zVx2UGQ67fWHFBLNzCPAJVd3kzzfw7ZtYgQnm1VFzlYO5ZJSED4Z46PKFI7
hMQOs08ApehV33Ta/6LN28RVfNdyEs5aLwmnrE8Y0VdcL7rLqemWqmVyy1W3Y9SyDelKJ0yo5Un2
cHWX1qkShMEqWth8f5CbFBU7k4kzKHVYcHiTGsUWjA7rwbMdH5IsxHQDvuo41n66JsckjTx8jXRN
J4kqjkjSAR80lCE/dsHrxQG493ri5zRWQ64btKLYQFOZj0FN8DY3SucDApfFk8+ZqB20kItj6cS4
h5YrDddw6FgtChEBAyk3XzIAi69nJnsJuBcd7eXhhyxTmOBz0iHX++wOsWzCIBcHPtznq7MOELNn
z9uPNKn+sCXNisUBX4n/32RkicSeTuWs6dF5LUUEEvafKzElMCMGCSqGSIb3DQEJFTEWBBTOafLz
SINGSd2kDjnMUo76hTjilDAxMCEwCQYFKw4DAhoFAAQUCNGGtHF/dtoHM4vFV6rwwyrOeeAECDWP
wCFEL+hYAgIIAA==
password: S0xXYUY4QWtSdW9mYW5VAA==
I put the certificate in a .p12 file, but I can't open it.
To overcome this issue I print the certificate to android storage: storage/emulated/0/output.p12 which created a file containing hexadecimal data. When I use this file to forward a request to my server using python:
$ python3
> from requests_pkcs12 import get
> r = get(url, pkcs12_filename='theOutput.p12', pkcs12_password='S0xXYUY4QWtSdW9mYW5VAA==')
I get the following error:
Error: [('asn1 encoding routines', 'ASN1_get_object', 'header too long')]
I feel that I have all the pieces of the puzzle and I only need to put them together, so my question is: How can I use the resources (certificate/password) I have retrieved to forward requests to the server?
Thank you.
I want to create a custom OpenVpn For Android client that satisfies my requirements. In typical mode , clients have a configuration file (.ovpn file) that they use to connect to OpenVpn server. Authentication procedure can be either username/password or certificate-based. But I want key generation procedure being done in client(mobile) not in server side and private key remains completely private and server doesn't access to it.
I mean changing code of openvpn for android client to generate key pair in TEE (trusted execution environment) of mobile and then creating CSR (Certificate Signing Request) and then sending CSR file to Openvpn server and server signs CSR file and create CRT (Certificate file) and send back to client. Client stores CRT file in TEE and communicate to OpenVpn server using Private key/Certificate in next times.
Is this scenario possible? Anyone has any idea about implementing this feature?
I mean changing code of openvpn for android client to generate key
pair in TEE (trusted execution environment) of mobile
This can easily be done in the TEE. Assuming you are using OPTEE-OS for example, then you can use the Global Platform API to generate a key pair from your Trusted Application. If you are using another TEE-OS this will of course be possible assuming they offer the functionality.
and then creating CSR (Certificate Signing Request)
Depending on the support offered by the TEE, this is also possible. OPTEE-OS has support for X509 certificates using mbedTLS.
Or, your Client application can ask the Trusted Application to get the public key under the PEM format and call openssl, mbedTLS or any other library to create the CSR.
and then sending CSR file to Openvpn server and server signs CSR file
and create CRT (Certificate file) and send back to client. Client
stores CRT file in TEE and communicate to OpenVpn server using Private
key/Certificate in next times.
Your client application would have to send the certificate request and inject the signed certificate to the Trusted Application, which then will have to check if the private key and public key of the certificate matches.
This is a possible scenario, however OpenVpn will need to have a way to verify the client, and thus, will have to call a function verify/certify which will use the stored certificate and private key in the TEE.
I have a question related to the use of MQTT protocol in Android environment. We are developing an Android application and using com.ibm.micro.client.mqttv3_7.5.0.0.jar MQTT client library in order to send push notifications to Android devices. My question is about SSL connection. In desktop applications, we copy our .keystore file in a proper location and refer to it as follows;
public Properties getSSLSettings() {
final Properties properties = new Properties();
properties.setProperty("com.ibm.ssl.keyStore",
"C:/BKSKeystore/mqttclientkeystore.keystore");
properties.setProperty("com.ibm.ssl.keyStoreType", "BKS");
properties.setProperty("com.ibm.ssl.keyStorePassword", "passphrase");
properties.setProperty("com.ibm.ssl.trustStore",
"C:/BKSKeystore/mqttclienttrust.keystore");
properties.setProperty("com.ibm.ssl.trustStoreType", "BKS");
properties.setProperty("com.ibm.ssl.trustStorePassword", "passphrase ");
return properties;
}
Above code works perfectly to get SSL settings. We implemented this code also in Android, but it is very clear that holding .keystore file(s) inside the device is not secure at all. My question is, is there any other alternative to implement SSL connection without storing .keystore file(s) inside device’ s internal or external storages?
In later versions of android you can access the device's keystore using KeyChain to provide access to private keys. For the trust store using the device's trust store works fine, which android uses by default for SSL connections. Also IBM have a messaging community which has information on using their libraries on mobile devices.
I am after a solution which would enable me to use the in-build keystore and StrictHostnameVerifier but would allow me to obtain the X590CertificateChain (either once connected or post handshake) so I can perform some additional checks (specifically I want to verify the root public key is the one I expected).
The examples I have investigated are mainly around overriding the behaviour (i.e. by replacing the socket factory or hostname checker with ones which don't do anything) and I am struggling with the differences between the android and other java implementations.
The reason I don't want to bundle a keystore (aside from having to use bouncycastle instead of jks) is that I don't want to package the intermediate CA cert with the app as this will create a certificate management problem sooner.
Many thanks in advance for any comments.
Ideally, this should be done at runtime. Bundling the certificate might be redundant as well, when some devices might already have that certificate installed.
Normally, your approach should be this.
Try connecting to the server.
If certificate is not installed, you will get a certificate exception. Catch it, extract the public certificate, save it, by creating a keystore on the fly.
While making new connections, use this keystore to initialize your SSL context.