SSL certificate on android device

[LiamClark]

If we are going to send the secrets through grpc, we should enable encryption. This however requires an ssl certifcate on every android devices for the netty server.

Maybe we could use Let's encrypt for this, they provice a few java libs to do certificate creation: https://github.com/zero11it/acme-client

However they all seem to require java 8. @eanker @GijsWeterings you guys had experience with letsencrypt right? what do you think?

[eanker]

If you want to create a SSL certificate, let's encrypt is indeed a very good option. Never used the lib you pointed to, because I only created them on a ubuntu server. However it seems to do what we need.

[GijsWeterings]

That lib hasn't been updated in a year, while I believe letsencrypt did change some things in their process... Does it still work? If it does, it's probably the best option, yes. Since it requires java 8, do we then limit devices?

[Griezzly]

I might get this totally wrong but it seems like we could just use grpc directly to get a certificate: https://github.com/letsencrypt/boulder/wiki/gRPC-authentication

[Recognition2]

Data encryption is typically done through TLS. While, yes, TLS often requires certificates signed by central authorities, this is only useful in the case of central trust. In the World Wide Web, we trust ICANN and many certificate authorities to ensure that the web server we're visiting is who they claim to be.

While somewhat relevant, this is not the issue at hand. We don't want to rely on the certificate authorities, which are central authorities, and we don't have domain names. As such, while Let's Encrypt is great for automated domain validation, it is not applicable to our use case.

Another possibility is generating a self-signed certificate. While in many typical use cases this is a "Bad Thing", consider the three guarantees that TLS with LE-certs gives you:

• Integrity, your data cannot be modified while in transit. It is impossible that you will receive only half of a sent message, and the content of the message cannot be modified in such a way that you will not notice;
• Confidentiality, nobody can view your content except the party which possesses the private key corresponding to the public key that is part of the certificate;
• Authentication, the party that corresponds to the public key of the certificate is in fact the person you are trying to talk.

The last part, authentication, is given by domain name validation. The other two parts do not depend on CA's, this is also the case with self-signed certificates.

So, we would need to implement authentication ourselves. This can be done by publishing the public key of your certificate on the blockchain. Because in our system the genesis block of the blockchain starts your identity, the authentication problem is moved to our blockchain.

This new problem is exactly the whole trust problem we're trying to fix in the first place. So self-signed certificates can solve our problem.

If this is done, please take care to use TLS1.2 (or even 1.3) with a "good" ciphersuite. I suggest an secp521r1 EC private key, and using TLS1.2 with ciphersuite one of the ECDHE-ECDSA-AES256-GCM-SHA{384,512} suites.

[LiamClark]

No longer needed :D