Trusting Identities
High level abstractions makes encryption simple. Smart key distribution also makes id management simpler by hiding crypto keys and digital signatures. However, the application still has to make sure the correct identities are used.
Introduction
When you encrypt a message, you have to ask yourself: who am I encrypting this for? This seems fairly obvious; encrypting to a random receiver is not very useful. The next problem is then to attain the correct user and key.
If you are not familiar with basic cryptography such as key negotiation, certificate distribution and the differences between symmetric and asymmetric crypto, we recommend you to first read our brief article Cryptography 101 before reading on.
Obtaining the correct key
As mentioned before, key distribution is often the real issue to solve when deploying systems for secure communication. The problem of obtaining the correct encryption key is central for security. Basically, the problem consists of tying a public key to a user ID.
This problem is very central and present in most situations. The most common solution is to use some form of trusted third party, where all trust is put in the correct acting of a central authority. For example, this is how trust is established in HTTPS. HTTPS uses a Public Key Infrastructure where trusted Certificate Authorities reside in the browser/operating system/application.
At HYKER, we aim for simplicity and established standards. But we also like diversity and granular control. Therefore we provide a hosted Public Key Infrastructure, but we also provide alternatives.
Trust establishment in the HYKER service is pluggable and can be done in the following ways:
HYKER hosted pki This alternative is the simplest alternative requiring no setup from the developer. Therefore it is the default alternative.
developer hosted pki This alternative is a simple alternative which gives control over the certificate authority to the developer. This is more granular than the HYKER hosted key distribution but requires a small amount of setup.
end customer hosted pki This alternative is analogous to the developer hosted PKI but even more granular.
voting systems such as CONIKS where trust is distributed among many authorities.
manual certificate distribution Aka: meet and greet. This alternative gives full control over key distribution to the users. By doing so, it also gives responsibilities to the users and is therefore not as simple as the other ones. Due to the more granular key authority control, it can be preferable in some cases.
Obtaining the correct user ID
Obtaining the correct ID is just as important as obtaining the correct key for that ID. A question that is seldom asked is "what does this identity represent, and who controls it". How do you know if you should encrypt for "real_elon_musk" or "official_elon_musk"?
Example scenarios are:
- Facebook identity The identity represents you, but Facebook controls it.
- An IoT node The identity represents a device, not a person, but the organization running the IoT service controls it.
- A PGP web of trust certificate The identity represent you, you control it, but trust from others is derived from the web of trust.
As seen in the above examples, you will have to think how to implement identity distribution in your service.
Every service is unique and may needs its own approach. Many services are however similar to others and can use a standard solution such as Active Directory for a centralized enterprise service or Keybase for a public messaging application.
For a hands on attempt to use public identities (what keybase is base on), hava look at out Chat App Use Case that highlights this challenge: