The Architecture page gives a high level understanding of the encryption approach taken for Yona. This page takes it a level deeper and describes the details. Yona employs symmetric (secret-key) and asymmetric (public-key) encryption. The asymmetric encryption approach allows us to implement the mailbox metaphor as given on the architecture page: everyone can put a letter in the box but only the one in possession of the key can read the them. The symmetric approach is used most commonly because of the performance benefits. The below picture provides an overview of the encryption approach:
The app contains a secret key (the Yona password, visualized above with the pink key) that is passed to the server in every request. The server uses this to decrypt the private data of the user, including information about buddies and goals, but also the private key of the two message boxes. The messages in the boxes are secured through the public/private key pair of that message box.
The class diagrams on the Architecture page show orange classes that contain private user information, encrypted with the Yona password. For this encryption, we use AES, with a random key that is generated by the server at the time the user account is created. This key is returned to the app as part of the private user data. With every subsequent request, the key is passed to the server in the
Yona-Password header. Every such request is executed in the context of a so-called
CryptoSession. This session is initialized with the key that was received through the
Yona-Password header. Code that needs to encrypt or decrypt data can fetch the current
CryptoSession and request it to encrypt or decrypt the data. The encrypted data in JPA entities is encrypted and decrypted through an
while storing/loading the entities.
The messages contain encrypted data too (shown in magenta on the Architecture page). For this, we use asymmetric encryption (RSA), but we combine that with symmetric encryption for performance reasons. Every message contains a property
decryptionInfo that contains the symmetric key used to encrypt the encrypted properties of that message. The
decryptionInfo itself is encrypted with the public key of that message box.
To see this more in depth, we focus on an activity comment message that one user sends to another. This is the relevant class diagram fragment:
To send that message, the we find the
MessageDestination by decrypting the private data of the sending user and then navigating from
UserPrivate to the appropriate
Buddy. Then to the
UserAnonymized and then the related anonymous
MessageDestination. On that, we call
sendMessage. That will result in the following steps:
The data can be depicted as follows:
It would have been possible to encrypt the relevant message properties with the public key, but that has three downsides: