-
Notifications
You must be signed in to change notification settings - Fork 7
Encryption
Application provides 2 security layers. The first one is provided by server-client autentication, authorization and connection encryption. But even if the first one fails (for example by secret server misuse), the architecture of application guarantee security and privacy.
The first security layer is descriped in Protocol documentation. It is based on TLS 1.2.
Each user has its own chain of blob messages, which is encrypted on server by various AES keys. (each sender has its own AES key) Once blob messages are downloaded, they are decrypted and saved to local database. The blob messages can contain the AES key itself to ensure their readability of future blob messages in chain.
Let's have user A and B. A and B haven't communicated on server to each other, but they would like to send messages. Only actions of A are descripted, but B must do analogically the same
A must download information about B (UserName, UserId, PemCertificate) from server, verify them and add them to the chain. After that A must send a trustification request to server with a new encrypted signed AES key (this is done if and only if the trustification is running first time). The AES key and trustification fact is also saved to the chain. Now can A send blob messages to B, but they are not delivered until B trustificate A. Even if server push them to B, B refuse to read them.
AES keys are generated using pseudorandom number generator. They have lenght 32 bytes. (256 bites) This is not raw form used by AES algorithm. AES key used by algorithm will be always explicatly marked as raw AES key.
AES encryption is mainly used for transfering blob messages. AES encryption doesn't use the convention. Everything is written to stream in raw form.
AES blocksize is 128 bites and salt lenght is 16 bytes. Algorithm is using RFC 2898 convension to derive IV and raw AES key (1000 iterations). AES is set to use CBC. Salt is always generated using pseudorandom generator.
First 16 bytes of encrypted byte[] are always salt bytes. The rest is the result of AES algorithm.
RSA encryption, decryption and signing is mainly use for sharing AES keys. The procedure will be descriped using streams. It is using this convention.
Let's have AES key (byte[]). We make its sign using SHA-256 hash and Pkcs #1 padding (S) and encrypt it using Pkcs #1 padding (E). S is evidently made using sender's certificate and E using receiver's certificate.
First, S is written to stream and after that E.
S and E are read from stream. S is verified and exception is thrown, if there is an error. E is decrypted and returned.
There are implemented pure encrypt and decrypt functions using OaepSHA256 padding. They are used during server-client authentication.
Certificates are always hashed by SHA-256 in pem format. First line is "-----BEGIN CERTIFICATE-----\n", two last lines are "-----END CERTIFICATE-----\n" and after every 76 chars of Base64 code is inserted line break.
For prove of security, we must analyse which informations client downloads, and argue about its safety.
These informations are used only if client connects first time. If bad UserName is provided by server, nothing really bad happens. If server provides bad UserId, client works as the new account is created.
When server provides bad ClientId, there can be conflicts in MessagesThreadId between two different clients. So client stops working, but no real security risk at all.
All AES keys are encrypted by receiver's X509 certificate and signed by sender's X509 certificate. It means, the server is not able to falsificate them. The only thing, it can really do, is a denial of sending it to client.
This is the most vulnerable place. Server sends informations about searched user and client must decide about validity of received certificate. Once user decide to trust downloaded information, it is saved as blob message to the chain.