Secure connection between two mobile devices: SSL key not 'private'

Question

I have SSL working between two Android devices running the same app using a self-signed cert and key generated using openssl and stored in keystores. The problem is that the private keystore must be embedded in the app package somehow, and therefore becomes available to any attacker. I believe this would allow an attacker to snoop on the session and decrypt the data between the two phones.

I'm not using or requiring any of the other features of PKI, I'm just providing two keystores because the SSL connection setup requires them.

Is there a secure SSL cipher that does not need predefined PKI and generates its own keys on the fly at runtime?

I have investigated generating my own keys at runtime - creating the keys is easily done in Java but the KeyStore.setEntry() requires an an X509 certificate chain not just the public key, and Android does not contain the JCE code to generate the X509. I can do that by including the BouncyCastle (Android compatible version is called SpongyCastle) library but that adds quite an overhead to my app package size.

There is no access to a third-party trust server on the internet, the two phones could be on a private WLAN with no internet access.

As a nice-to-have bonus I'd like to be able to trust that the app is communicating with itself, not someone sniffing the protocol from a PC, but I don't think that's going to be possible as the app package contents will always be available.

Answer 1

To ensure you are talking to something/someone you trust, you need a mechanism of authenticating the other party. I'm not aware of a way to achieve this without a piece of data remaining secret:

• Asymmetric authentication (ie your current implementation) requires the private key data to remain private.

• Symmetric authentication requires that the shared secret remains private.

In the future, TrustZone will allow applications to store secret data in the secure element of the handset. Until that time, however, you are always at risk of malware on your devices. Adding a password to your keystore (that the user knows, not the app) might add an additional hurdle to an attacker, however once the phone is infected then the password can be snooped.

To minimise your risk profile you should produce per-device keys, rather than a single cert/key-pair combo that you incorporate into your application. This will, of course, increase the effort required to add new users as some form of registration will be required (eg certifying their key). Alternatively you can push the problem out to your users and have them decide who to trust, PGP-style.