Sikkerhed i Uniconta

Uniconta Arkitektur

Uniconta er en 3 tier arkitektur.

Klienten har kun en forbindelse til Uniconta applikation serveren (UAS) og UAS er den eneste forbindelse til SQL’en.

UAS loader en del ”state” ind fra SQL og det forbliver så i UAS og skrives så ned i SQL ved opdateringer. Men ved en læsninger, så serviceres kaldet direkte fra UAS.

Uniconta har kun en SQL database og alle data ligger i samme SQL. Alle relationer i SQL er via RowId, og ikke via ”nøgler”.

Dvs at en debitor har et helt unik RowId i hele SQL’en og alle posteringer til den debitor referer til denne debitors RowId.

På debitoren står hvilket firma den tilhører, men det står ikke på posteringen hvilket firma den tilhører. Den tilhører kun en debitor.

Og sådan er det med alle tilhørsforhold. De tilhører en master via et SQL unikt RowId.

Kommunikation mellem klient og server:

Uniconta bruger Uniconta.WindowsAPI

Uniconta.WindowsAPI bygger på standard .NET og har kryptering.

Vores server har genereret et ” X509Certificate2” på vores server.

Det er et certifikat som har en public key og en private key.

Det første API’et gør ved opstart er at kalde serveren og bede om public nøglen. Den sender vi helt u-krypteret. Den er per definition public.

Herved bliver pakker fra klienten sendt til serveren krypteret via denne public key. Den eneste der kan dekryptere denne pakke er vores server, da den har den private key, der skal bruges for at dekryptere pakken.

Når klienten kalder login vil den i pakken inkludere, username, password, en random genereret 32 bit lokal krypterings nøgle (K1) og en 64 bit login Ident nøgle(K2)

Når serveren medtager pakken vil den dekrypteres via sin private key, og så udpakkes login kaldet.

Så checkes om username og password eksisterer. Eksisterer det så oprettes en session på serveren. Denne session bliver identificeret ved en autogenereret GUID.

Sessionen vil blive tildelt de 2 ”koder” fra klienten  K1 og K2. Sessionen vil også blive tildelt et sequence number 1.

Når serveren returnerer pakken til klienten, så inkluderer pakken GUID og K2, og den krypteres med K1 nøglen.

Når Klienten modtager login pakken, så dekryptere den først med K1 nøglen, som den selv har genereret og klienten vil så checke om den får K2 tilbage.

Den vil gemme GUID, som skal bruges til fremtidige kald.

Nu er klienten connected.

Næste pakken til serveren vil indeholde GUID og sequence number 2, og den bliver krypteret med public key,

Serveren vil dekryptere med private key. Serveren vil finde sessionen via GUID. Serveren vil se om sequence number 2, har været modtaget før. Har den ikke det, vil kaldet bliver registreret at sequence number 2 er modtaget. Nu vil kaldet blive behandlet og på retur pakken vil den blive krypteret med K1 nøglen.

Hvis en anden vil opsnappe login pakken som sendes TIL serveren, og lave en Replay, så vil serveren afvise pakken idet K2 allerede eksisterer, så ingen med den samme K2 kan komme på.

Hvis en anden vil opsnappe de andre pakker som sendes TIL serveren, og lave en Replay, så vil serveren afvise pakken idet sequence nummeret allerede er behandlet.

Hvis en anden vil opsnappe de andre pakker som sendes RETUR fra serveren, så vil han ikke kende K1 nøglen og ikke dermed ikke kunne dekryptere pakken.

Alle brugeren har jo selv genereret sin egen K1 nøgle og derved vil alle retur pakker blive krypteret forskelligt.

En pakke der sendes til serveren krypteret med en public key af typen ” X509Certificate2” er stort set umulig at dekryptere.

Det er det alle sværeste at dekryptere. Kun den der har private key kan dekryptere den. Denne Private key forlader aldrig serveren.

Alle pakker som sendes retur fra serveren, vil ikke indehold noget om hvilet kald der blev kaldt. Den vil kun indeholde resultatet. Så en pakke kan sagtes blot indehold ”ok”. Eller ”100” eller blank. Der er ingen mulighed for på nogen måde at se på returpakken hvad den returnere fra.

Vi har 113 forskellige kald, som alle returnere binær data og ingen data om hvad pakken indeholder. Så selvom du kan de compilere vores api og dermed regne dig frem til hvordan pakken skal pakkes ud, så ved du stadig ikke hvilen pakke det er. Og det er først efter at du har formået et dekryptere pakken med en nøgle, som du heller ikke kender.

Læs om hvor Password gemmes i Windows