Uniconta Architecture
Uniconta is a 3-tier architecture.
The client only has one connection to the Uniconta application server (UAS) and UAS is the only connection to the SQL.
UAS loads some "state" from SQL and it stays in UAS and is then written to SQL during updates. But on a read, the call is serviced directly from UAS.
Uniconta has only one SQL database and all data is stored in the same SQL. All relationships in SQL are via RowId, not via "keys".
This means that a debtor has a unique RowId throughout the SQL and all postings to that debtor refer to that debtor's RowId.
The debtor shows which company it belongs to, but the entry does not show which company it belongs to. It only belongs to one debtor.
And so it is with all affiliations. They belong to a master via a SQL unique RowId.
Communication between client and server:
Uniconta uses Uniconta.WindowsAPI
Uniconta.WindowsAPI is based on standard .NET and has encryption.
Our server has generated an "X509Certificate2" on our server.
It is a certificate that has a public key and a private key.
The first thing the API does at startup is to call the server and ask for the public key. We send it completely unencrypted. It is public by definition.
This way, packets from the client sent to the server are encrypted via this public key. The only one that can decrypt this packet is our server, as it has the private key needed to decrypt the packet.
When the client calls login it will include in the packet, username, password, a randomly generated 32 bit local encryption key (K1) and a 64 bit login Ident key (K2)
When the server takes the packet, it will be decrypted via its private key, and then the login call is extracted.
Then check if the username and password exist. If it exists, a session is created on the server. This session is identified by an auto-generated GUID.
The session will be assigned the 2 "codes" from the client K1 and K2. The session will also be assigned a sequence number 1.
When the server returns the packet to the client, the packet includes the GUID and K2 and is encrypted with the K1 key.
When the client receives the login packet, it first decrypts with the K1 key that it has generated itself and the client will then check if it gets K2 back.
It will store the GUID to be used for future calls.
Now the client is connected.
The next packet to the server will contain GUID and sequence number 2, and it will be encrypted with public key,
The server will decrypt with private key. The server will find the session via GUID. The server will see if sequence number 2 has been received before. If not, the call will be registered that sequence number 2 has been received. Now the call will be processed and on the return packet it will be encrypted with the K1 key.
If someone else wants to intercept the login packet sent to the server and do a Replay, the server will reject the packet because K2 already exists, so no one with the same K2 can get on.
If someone else wants to intercept the other packets sent to the server and do a Replay, the server will reject the packet as the sequence number has already been processed.
If someone else wants to intercept the other packets sent BACK from the server, he will not know the K1 key and will not be able to decrypt the packet.
Each user has generated their own K1 key and therefore all return packets will be encrypted differently.
A packet sent to the server encrypted with a public key of type "X509Certificate2" is virtually impossible to decrypt.
It is the hardest thing to decrypt. Only the person who has the private key can decrypt it. This private key never leaves the server.
All packets sent back from the server will not contain anything about which call was made. It will only contain the result. So a packet can simply contain "ok". Or "100" or blank. There is no way to tell from the return packet what it is returning from.
We have 113 different calls, all of which return binary data and no data about what the package contains. So even if you can compile our api and figure out how to unpack the package, you still don't know which package it is. And that's only after you've managed to decrypt the packet with a key that you don't know either.
Read about where passwords are stored in Windows