Certificate pinning xamarin forms - xamarin

Question

Confused on how to do certificate pinning. How do we instll the certificate in n android or ios device through xmarin forms. Is this done during installation if application? There are some tutorils on how to use validation of https requests using pinning but nothing bout installation of the public certificate?

Answer 1

Another way to go is to perform pinning on the leaf's certificate public key and in this simple demo class we can see how to do it when using the HttpClient by customizing the ServicePointManager:
using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;
namespace ApproovSDK
{
/**
* Service point configuration.
*
* Adds simple pinning scheme to service point manager.
*
* FOR DEMONSTRATION PURPOSES ONLY
*/
public static class ServicePointConfiguration
{
private static string PinnedPublicKey = null;
public static void SetUp(string key = null)
{
PinnedPublicKey = key;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
ServicePointManager.ServerCertificateValidationCallback = ValidateServerCertficate;
}
private static bool ValidateServerCertficate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors
)
{
if (PinnedPublicKey == null || PinnedPublicKey.Length <= 0) return true;
//Console.WriteLine("Expected: " + PinnedPublicKey);
//Console.WriteLine("Found : " + certificate?.GetPublicKeyString());
return String.Equals(PinnedPublicKey, certificate?.GetPublicKeyString(),
StringComparison.OrdinalIgnoreCase);
}
}
}
The above example was written for demo purpose and a better implementation should associate multiple keys for each domain being called.

Answer 2

While you can use the certificate itself in order to perform your validation and thus pin the certificate there are alternative options.
As per the OWASP documentation here you can implement any of the following 3 approaches:
Certificate
The certificate is easiest to pin. You can fetch the
certificate out of band for the website, have the IT folks email your
company certificate to you, use openssl s_client to retrieve the
certificate etc. When the certificate expires, you would update your
application. Assuming your application has no bugs or security
defects, the application would be updated every year or two. At
runtime, you retrieve the website or server's certificate in the
callback. Within the callback, you compare the retrieved certificate
with the certificate embedded within the program. If the comparison
fails, then fail the method or function.
There is a downside to pinning a certificate. If the site rotates its
certificate on a regular basis, then your application would need to be
updated regularly. For example, Google rotates its certificates, so
you will need to update your application about once a month (if it
depended on Google services). Even though Google rotates its
certificates, the underlying public keys (within the certificate)
remain static.
Public Key
Public key pinning is more flexible but a little trickier due to the
extra steps necessary to extract the public key from a certificate. As
with a certificate, the program checks the extracted public key with
its embedded copy of the public key. There are two downsides two
public key pinning. First, its harder to work with keys (versus
certificates) since you usually must extract the key from the
certificate. Extraction is a minor inconvenience in Java and .Net,
buts its uncomfortable in Cocoa/CocoaTouch and OpenSSL. Second, the
key is static and may violate key rotation policies.
Hashing
While the three choices above used DER encoding, its also acceptable
to use a hash of the information (or other transforms). In fact, the
original sample programs were written using digested certificates and
public keys. The samples were changed to allow a programmer to inspect
the objects with tools like dumpasn1 and other ASN.1 decoders.
Hashing also provides three additional benefits. First, hashing allows
you to anonymize a certificate or public key. This might be important
if you application is concerned about leaking information during
decompilation and re-engineering.
Second, a digested certificate fingerprint is often available as a
native API for many libraries, so its convenient to use.
Finally, an organization might want to supply a reserve (or back-up)
identity in case the primary identity is compromised. Hashing ensures
your adversaries do not see the reserved certificate or public key in
advance of its use. In fact, Google's IETF draft websec-key-pinning
uses the technique.
I would strongly recommend using the Hashing approach meaning that when you validate the certificate coming in you just need to check that the hash of the certificate coming from the server is the one(s) that you expect. Something like the following:
private bool ValidateServerCertificate(object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
// Make sure we have a certificate to check.
if (certificate == null)
{
return false;
}
if (sslPolicyErrors != SslPolicyErrors.None)
{
return false;
}
return this.KnownKeys.Contains(certificate.GetCertHashString(),
StringComparer.Ordinal);
}
Where KnownKeys is a simple compile time defined array of your known certificate hashes:
private readonly string[] KnownKeys = new[]
{
"INSERT HASH",
"AND A SECOND IF REQUIRED"
};