Uniconta has a three-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 a partial ”state” from SQL and it remains in the UAS and is entered into SQL when updates are made. However, when read, the call is serviced directly from the UAS.
Uniconta has one SQL database and all data is in the same SQL. All relations to the SQL occur via RowId, not using ”keys”.
So a debtor has a unique RowId for the whole SQL and all transactions with that debtor refer to this debtor’s RowId.
The debtor is linked to the company information for that debtor’s company. However, the company information is not linked to each transaction.
This is the case for all affiliations, i.e. they are linked to master data via a unique SQL RowId.
Communication between the client and the server
Uniconta uses Uniconta.WindowsAPI
Uniconta.WindowsAPI builds upon a standard .NET and is encrypted.
Our server has generated a ” X509Certificate2”.
This is a certificate with both a public and private key.
Upon startup, the API calls the server and requests the public key. This is then sent completely un-encrypted (so it is public by definition).
Encrypted packages are thereby sent from the client to the server, using this public key. Only our server is able to decrypt the package, since it has the required private key.
When the client creates a login, this includes a username, password, a randomly generated 32 bit local encrypting key (K1) and a 64 bit login Ident key (K2).
When the server receives the login package it is decrypted using its private key and the login name is unpacked.
It then checks to see whether the username and password exist. If they exist, then the server starts the session. This session is identified with an automatically generated GUID.
Two ”codes” for clients K1 and K2 are assigned to the session. The session is also assigned sequence number 1.
When the server returns the package to the client, it includes the GUID and the K2, and it is encrypted with the K1 key.
When the client receives the login package it is decrypted with the K1 key it has generated and the client checks that it receives the K2.
The GUID is saved for future calls.
The client is now connected.
The following package to the server includes the GUID and sequence number 2, which is encrypted with the public key.
The server decrypts it using the private key. The server finds the session using the GUID. The server looks to see whether it has received sequence number 2 before. If it has not, then the call registers that sequence number 2 has now been received. The call will now be processed and the K1 key is encrypted on the return package.
If anyone else tries to use the login package sent TO the server and perform a Replay, then the server rejects the package since the K2 already exists. This means that no-one with the same K2 can gain access.
If anyone else tries to use the other packages that are sent TO the server and perform a Replay, then the server rejects the package since the sequence number has already been used.
If anyone else tries to use the other packages that are sent BACK from the server then they will not have the K1 key and therefore cannot decrypt the package.
All users have generated their own K1 key, so all return packages will be encrypted differently anyway.
A package that is sent to the server encrypted with a ” X509Certificate2” public key, is virtually impossible to decrypt.
It is the most difficult key to decrypt. Only the person with the private key can decrypt it. This private key never leaves the server.
None of the packages returned from the server contain any information on which call was used. They only contain the result. So a package might just contain ”ok” or ”100” or it might be blank. There is no way to view the return package.
Uniconta has 113 different calls, all of which return binary data and no data on the contents of the package. So even if someone manages to compile our API and thus figure out how to view the package, they still do not know which package it is. That would only be possible after they had managed to decrypt the package with a key that they don’t have access to anyway.