If you're not bothering with the HTTP protocol then you don't even need a certificate at all. You just need to have something like SSH's 'known_hosts' file. All you need to know when initiating communication over a secure channel is that the key the server sent you is in fact the key for the server. In fact, if you're including something with the app, just include the servers public key directly. Forget the whole key exchange process. Then use the server's public key to send a symmetric key generated by the app itself (sort of like TLS does) for the duration of the connection. This provides forward secrecy as well. Simple. Elegant. Secure.The only catch is that if you change the server's key it will break all clients. However, you could always hard code a second public key that isn't even contained on your servers that is used as a fallback for catastrophic incidents where your private key gets exposed. Once you fix your security hole you swap out your key to your fallback and clients are secure again.
thegeomaster|11 years ago
Furthermore, a compromised pseudorandom number generator on the client can compromise the security of communication. To mitigate that, at least partly, both parties in my scheme contribute half of a session AES key.
jwarkentin|11 years ago