When using Google SafetyNet for Android the documentation suggest that you
Validate the SSL certificate chain and use SSL Hostname matching to
ensure the leaf certification was issues to attest.android.com
Now how does this work? I would have assumed that I get the JWS message inspect the certs and signature etc but would validate against a cert grabbed from attest.android.com, but attest.android.com is not a live host.
Does SSL signing cater for validation without previously knowing the public key of the domain? i.e. Can I validate everything from incoming JWS message? I don't see how this is possible, is it?
Unfortunately, the documentation is not very descriptive as what you have to do.
The JWS data includes three sections: the header, the payload and the signature. Simplifying things, the header contains the public key certificates used to sign the payload, and the signature is included at the end.
To validate a SafetyNet JWS, you first need to extract the certificates embedded in the header. These certificates have trust chains that can be validated to a public root certificate, so you should verify that these are indeed valid certificates, and that they are issued to attest.android.com.
Then you take out the signature, and verify it against the embedded certificates.
If you check this, then you can trust the payload. But before looking at basicIntegrity and ctsProfileMatch, please ensure that apkPackageName, apkDigestSha256 and apkCertificateDigestSha256 match those of your app, so you know that the response actually comes from your unmodified app.
Optimally, your programming language should include a JWS library and an SSL library that can do this for you, so you don't have to write this yourself. The public sample includes a Java sample for you to peruse.
Related
I need a secured connection between the client(Android application) and server. I referred official document developer.android.com/training/articles/security-ssl.html. And also found here globalsign.com/en/ssl-information-center/… that there are three types of ssl certificate:
Extended Validation (EV SSL) Certificates
Organization Validated (OV
SSL) Certificates
Domain Validated (DV SSL) Certificates
Which of the above supported in android app?(not in the browser.I am using retrofit to call web services), And Which one should I use?
As stated by Steffen Ullrich, any of the listed SSL certificates will work for your purposes. The primary difference between those options that you have listed is the extent to which the certificate authority will go to in order to verify your identity.
The scrutiny given to any certificate request can range from very little (no verification beyond domain name ownership) to the requester needing to provide the CA with proof of a physical location.
For your purposes, encrypting traffic from an android application to an API, any of the listed cert types would work and I would go with the cheapest option.
I would recommend: https://letsencrypt.org/docs/ to get what you need.
Additionally, just to add some more context to your question and your specific Android tag. It actually has little to do with Android and more to do with the server you'll be communicating to. Getting an SSL cert installed on your server means that you'll be able to encrypt traffic from any source to that server and the only thing you'll need to do from an android perspective is to ensure you hit port 443 (https://)
I'm trying to understand how the jwt signature validation works.
This is how I'm doing it at the moment:
1) My app calls the attest api
2) My app sends the jwt to my server
3) My server verify the signature (third field of the jwt) using the certificate provided in the header of the jwt.
I understand that the signature is created by hashing the header and the payload of the jwt and then signing it (encrypting it) with Google's private key.
What I do in my step 3 is that I take the header + payload and decrypt it with
certificate's public key and verify that it matches the signature. (when I say 'I' do I mean a lib does it)
My issue is that, what happens if there is a malware on the user device and amend on the fly the JWT that is sent to my server? The malware would add his own certificate (issued by a trusted CA) in the header, modify the payload as it wishes and created the signature.
Me server side... well I'm going to take the public key provided in the cert valid the signature with it which will matches.
Is this correct? Or I'am confused somewhere? Because in that case it would render this all flow a bit useless no? How doe insure myself 100% that the JWT comes from google?
The key point is verify that the signing certificate is issued to attest.android.com by a trusted Certificate Authority
Any trusted CA will issue a fake certificate to attest.android.com. See what happens if they engage in bad practices https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html?m=1
See Google's doc
Verify the compatibility check response
You should take steps to make sure that the compatibility check response actually came from the SafetyNet service and includes data that matches your request data.
Caution: You should send the entire JWS response to your own server, using a secure connection, for verification. We don't recommend that you perform the verification directly in your app because, in that case, there is no guarantee that the verification logic itself hasn't been modified.
Follow these steps to verify the origin of the JWS message:
Extract the SSL certificate chain from the JWS message.
Validate the SSL certificate chain and use SSL hostname matching to verify that the leaf certificate was issued to the hostname attest.android.com.
Use the certificate to verify the signature of the JWS message.
Check the data of the JWS message to make sure it matches the data within your original request. In particular, make sure that the nonce, timestamp, package name, and the SHA-256 hashes match.
The second dot requires to validate the certificate chain. It is assumed that it is used a Trust Manager containing the root certificate of the Certificate Authority
I have inspected Google's sample code in OfflineVerify to ensure the existence of a TrustManager because it is not explictly said, and it is effectively used during JWS verification. It uses the default system TrustManager, but you can use a custom one
Note that is used JWS (Json Web Signature), not JWT. A JWT is usually an authentication token signed with JWS
You did grasp the concept correctly. However something that you overlooked is that the lib you use is probably verifying that the certificate from which it extracts the public keys is a valid and a 'trusted' certificate (AKA comes from a trusted CA)
Thanks to this (and like the doc points it out) you need to verify yourself that the certificate has been issued by a "attest.android.com". No one will be able to forge a certificate to make it comes from this CA because.
This is what I understood at least, please correct me if I am wrong.
In my Android app I want to use a https connection to a USER-SPECIFIED server which uses a self-signed certificate.
Because the https server is user specified, I don't know the server's certificate before, therefore I want to:
get the server's certificate dynamically
add this certificate's public key to the app's trust store
authenticate the server
I do NOT want to simply accept every self-signed certificate without the user checking the certificate
I am struggling with the first step, can anybody show me a working example with basic explications?
Any hints are appreciated. Thanks a lot
I haven't tried it but this looks promising:
https://github.com/cesarferreira/Android-Self-Signed-SSL-certificate-example
I want to perform extra validation for SSL connections I make in an android app.
Basically I need to be able to:
See if the certificate of the remote host I am connected to has Extended Validation (EV) status
Find out the root certificate authority for the certificate of the remote end. E.g. I want to know if it is a VeriSign certificate or not.
To elaborate a bit more, I am writing a client that needs a high level of security and our organization is using EV certificates from VeriSign on all servers. I want to prevent any compromised certificate authority, or anyone that can fool a certificate authority to forge a certificate for our domain be able to hijack the application.
Is this doable and if so, how? Is there a way to get more information about the certificate of the remote end from a URLConnection object or a HTTPClient object and so on?
First: you can't possibly 'prevent any compromised certificate authority' from issuing a certificate for your domain. If it is compromised, they can issue whatever they want. What you can do is create a trust store with a limited number of trusted CA certificates, say, VeriSign only. That way, even if an related CA is compromised and issues a cert for your domain, it wouldn't matter since you don't trust it in the first place. That would also take care of second bullet. To have additional checks you need to implement and install your own X509TrustManager. Check the JSSE reference guide for details.
I am developing an Android app which need to consume .Net webservices over SSL which I have no experience in. Now I am looking for some guidance and explanation on SSL handshake and certificates.
Note: the server is using IP address and NOT domain name. It is an intranet application.
So far I have created a certificate(called self-signed?) in web server from IIS 7.
To consume it from Android app, I found two ways of doing it :
1). Embedded the certificate in the app (Which certificate? How do I get it?)
2). Trust all the certificates ( ppl said there is security issue with this approach, could you elaborate more? Does it still do the handshake?)
CERTIFICATES:
How many type of certificates are there in the handshake and what are they?
Does self-signed certificate have root certificate? If yes, how can i get them?
Is it possible to move/copy the self-signed certificate from one server to another?
HANDSHAKE:
First of all, is this process correct?
The SSL handshake process(copied from a website) is described below:
The client initiates the SSL handshake process by sending a URL
starting with the following: https:// to the server.
The client initially sends the Web server a list of each encryption
algorithm which it supports. Algorithms supported by SSL include RC4
and Data Encryption Standard (DES). The client also sends the server
its random challenge string which will be utilized later in the
process.
Will the embedded cert be sent in here?
The Web server next performs the following tasks:
Selects an encryption algorithm from the list of encryption
algorithms supported by, and received from the client.
Sends the client a copy of its server certificate.
Sends the client its random challenge string
The client utilizes the copy of the server certificate received from
the server to authenticate the identity of the server.
The client obtains the public key of the server from the server
certificate.
The client next generates a premaster secret. This is a different
random string which will in turn be utilized to generate the session
key for the SSL session. The client then encrypts a different value
called the premaster secret using the public key of the server, and
returns this encrypted value to the server. This is accompanied with
a keyed hash of the handshake messages, and a master key. The hash
is used to protect the messages exchanged in the handshake process.
The hash is generated from the former two random strings transmitted
between the server and the client.
What is a master key?
The server sends the client a keyed hash of all the handshake
messages exchanged between the two parties so far.
What is this keyed hash made from?
The server and the client then generate the session key from the
different random values and keys, and by applying a mathematical
calculation.
The session key is used as a shared secret key to encrypt and
decrypt data exchanged between the server and the client.
The session key is discarded when the SSL session either times-out or is terminated.
I'll try to answer to the best of my knowledge here
Embedded the certificate in the app (Which certificate? How do I get it?)
This the certificate identifying the client's/app identity. You can either get it through CA or self signed. This certificate will be used by the server to verify the client's/app identity
Trust all the certificates ( ppl said there is security issue with this approach, could you elaborate more? Does it still do the handshake?)
It still does the handshake but it doesn't do the certificate validation which is dangerous unless you are connecting internally (which seems you are). Trusting all certificate means an entity can claim as someone who they are not and thus could obtain confidential information from the users.
How many type of certificates are there in the handshake and what are they? In handshake you have the server's certificate and optionally the client certificate (for two factors authentication)
Does self-signed certificate have root certificate? If yes, how can i get them? Root certificate as far as I know means the ones that identifies by CA itself and thus it has no else to sign it. As your identity can still be verified and needs to be signed by CA, yours would not be classified as root certificate
Is it possible to move/copy the self-signed certificate from one server to another? The short answer is yes though the procedures from one platform to the others are different. Check [this link)(http://www.sslshopper.com/how-to-move-or-copy-an-ssl-certificate-from-one-server-to-another.html), it has instructions to copy certificate for few platforms
Will the embedded cert be sent in here? No, the embedded (client's) certificate is sent after validation of the server's identify is complete
What is a master key? Master key is the key that is used to derived the session key for later communication. It is also used to hash the messages and to verify authenticity of the messages in the next set of stages
What is this keyed hash made from? It's made from the master key sent by the client. In order to verify all messages, the server sent all messages that have been passed and hashed it with the master key. The client will hashed its messages as well with the same key and then compared with the data sent by the server. Only when the hash matches then we could be sure we are still communicating with the same server