AppDevelopment: Create Certificate in app itself

Question

My customer is creating an certificate within a fat client so in the end he is using a server certificate and an individual client certificate that was created after the app installation. Now both client and server validate each others certificate.

I was asked if this approach is possible with an iOS and Android app. All I found on the web is that always the server creates the certificate and the public key is deployed with the app.

Any suggestions regarding this? Will it provide an extra layer of security?

Answer 1

The simple answer is yes, you can create a key within an app - there are several libraries to do this in the Java domain, for example, mostly built on the Java JCE Api standard:

• http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html

There are options around how you use the library and provider, and there are also standalone cryptography libraries most notably BouncyCastle, and it's Android derivative SpobgyCastle:

• https://rtyley.github.io/spongycastle/

There is a slightly old but very nice answer here that gives a good background on Android: https://stackoverflow.com/a/9965964/334402

There is a good note in the Java Cryptography document above, also:

WARNING: The JCA makes it easy to incorporate security features into your application. However, this document does not cover the theory of security/cryptography beyond an elementary introduction to concepts necessary to discuss the APIs. This document also does not cover the strengths/weaknesses of specific algorithms, not does it cover protocol design. Cryptography is an advanced topic and one should consult a solid, preferably recent, reference in order to make best use of these tools.

You should always understand what you are doing and why: DO NOT simply copy random code and expect it to fully solve your usage scenario. Many applications have been deployed that contain significant security or performance problems because the wrong tool or algorithm was selected.

You'll find this echoed in many cryptography texts also - essentially it is saying that your security is only as strong as the weakest link, and there is a danger of adding cryptography to an app and thinking everything is then fine.

An easy to understand example of the weakest link is if you generate a very strong private/public key pair, but then have weak security around the private key itself allowing a hacker debug your application to discover it.

Answer 2

My customer is creating an certificate within a fat client so in the end he is using a server certificate and an individual client certificate that was created after the app installation. Now both client and server validate each others certificate.

Any suggestions regarding this?

You have one of two models to use (that I am aware). In the first model, the organization runs a private PKI and the server issues the client certificates. in the second one, the client issues its own certificates.

For the first model, you should probably use the Simple Certificate Enrollment Protocol (SCEP). It allows users and devices to register with the organization or server. The organization can also password protect the enrollment, and send the password out-of-band (like email).

Peter Gutmann recently took over the RFC draft. I believe Microsoft calls is something else, and their server is called a NDES server.

For the second model, then you should probably use Origin Bound Certificates (OBC). They are "tear-off" certificates created on the fly when the client needs them. The server trusts them on first use (TOFU).

---

Will it provide an extra layer of security?

It depends. We need to see the threat model and existing security controls. Then, we need to determine if SCEP or OBC closes additional gaps over the existing controls.