Gå ut fra at serverne er kompromittert

Før en oppføring i det hele tatt havner i lageret, krypteres payloaden med en symmetrisk nøkkel (AES-256-GCM). Denne krypteringen hører til datamodellen, ikke til transporten. Serveren som lagrer oppføringene, kan ikke lese innholdet — den ser bare krypterte byte.

Når serveren svarer på en synkroniseringsforespørsel, pakker den payloadene i et ekstra RSA-krypteringslag med den offentlige nøkkelen til brukeren som spør. Selv den som fanger opp HTTP-svaret, kan ikke dekryptere det uten mottakerens private RSA-nøkkel.

All kommunikasjon går over TLS. Det beskytter metadata (oppførings-ID-er, tidsstempler, forespørselsparametre) som payload-lagene ikke dekker. Til sammen sikrer de tre lagene dataene fullt ut: lagret, underveis og på linjen.

Alle dokumenter krypteres med tenantens AES-256-standardnøkkel med mindre en annen nøkkel er angitt. Hver registrerte bruker får denne nøkkelen under onboardingen. Passer for alminnelige data i hele tenanten.

For sensitive dokumenter lager du en navngitt krypteringsnøkkel og deler den bare med berettigede brukere. Nøkler reiser offline (den krypterte nøkkelen på e-post, passordet på telefon eller ansikt til ansikt) eller admin-blindt gjennom en policy: en bruker som har nøkkelen, pakker den for hver mottaker med mottakerens personlige offentlige (RSA-)nøkkel, så en administrator kan distribuere den uten noen gang å lese den. Bare de som har nøkkelen, kan dekryptere.

En egen nøkkel som utelukkende krypterer katalogens tilgangskontrolloppføringer (brukerregistreringer, tilbakekallinger, grupper). Serverne bruker den til å kontrollere hvilke signeringsnøkler som er betrodd — uten å se brukernavn eller forretningsdata. Brukernavn ligger som SHA-256-hasher; de faktiske navnene er kryptert med administratorens RSA-nøkkel.

Hver synkroniseringsøkt starter med et challenge-response-handshake:

• Klienten sender sin offentlige signeringsnøkkel til serveren
• Serveren finner nøkkelen i katalogen og sender en tilfeldig challenge
• Klienten signerer challengen med sin private nøkkel
• Serveren kontrollerer signaturen, sjekker tilbakekallingsstatus og utsteder et kortlevd JWT

Ingen passord og ingen øktdatabase på serveren. En tilbakekalt bruker kommer ikke engang i gang med autentiseringen.

Nye brukere kommer inn gjennom et handshake i tre trinn der private nøkler aldri forlater enheten:

• Tilkoblingsforespørsel — Den nye brukeren genererer nøkler lokalt og lager en forespørsel som bare inneholder offentlige nøkler. Den kan trygt deles over hvilken som helst kanal.
• Godkjenning fra administrator — Administratoren registrerer brukeren i katalogen og krypterer de symmetriske nøklene med et delingspassord til engangsbruk.
• Utveksling over to kanaler — Tilkoblingssvaret går på e-post eller chat; delingspassordet formidles separat på telefon eller ansikt til ansikt.

• Signering: Ed25519 (128 bits sikkerhet, elliptisk kurve)
• Payload-kryptering: AES-256-GCM (256 bits sikkerhet)
• Transportkryptering: RSA-OAEP med SHA-256 (3072-bits nøkler)
• Nøkkelderivering: PBKDF2 med eget salt per nøkkeltype
• Token-signering: HMAC-SHA256
• Hashing: SHA-256 (innholdsadressering, skjulte brukernavn)

• Konfidensialitet: AES-256-GCM-kryptering — bare de som har nøkkelen kan lese
• Autentisitet: Ed25519-signaturer — beviser hvem som laget hver endring
• Integritet: Hash-kjeding — tukling bryter kjeden og oppdages på hvert punkt
• Ikke-fornektelse: Signaturer kan ikke forfalskes — opphavet er beviselig
• Personvern: Brukernavn hashes og krypteres — serveren kan ikke identifisere brukere

• Serverinnbrudd — Angriperen får bare chiffertekst og offentlige nøkler. Ingen klartekst, ingen private nøkler, ingen brukernavn.
• Avlytting av nettverket — Tre krypteringslag beskytter dataene selv om TLS er kompromittert.
• Uautoriserte endringer — Hver endring er signert; usignerte eller feil signerte endringer avvises.
• Tukling — Hash-kjeding gjør enhver endring synlig.
• Tilgang for tilbakekalte brukere — Tilbakekallingen virker både ved challengen og ved kontrollen av tokenet; synkroniseringen blokkeres umiddelbart.
• Avlytting på relay — Relay-noder lagrer og videresender krypterte oppføringer de ikke kan dekryptere.

Innholdet i payloaden er alltid kryptert, men noen metadata ser serveren med hensikt. Det er en bevisst avveining: synkroniseringsprotokollen trenger metadata for å avstemme oppføringer.

• Synlig: Tidsstempler på oppføringer, innholdshasher, dokumentstruktur (hvor mange oppføringer per dokument), tilgangsmønstre (når brukere synkroniserer)
• Ikke synlig: Dokumentinnhold, brukernavn, krypteringsnøkler, innholdet i vedlegg

Innholdshasher avslører når to oppføringer inneholder identiske krypterte data (til deduplisering). Det er en akseptert avveining for lagringseffektiviteten.

Å tilbakekalle en bruker blokkerer all videre synkronisering og avviser brukerens framtidige endringer. Data som alt er synkronisert til enheten, er likevel fortsatt tilgjengelige — ingen systemer kan garantere sletting på en enhet som aldri kobler seg til igjen. Mottiltak: bruk navngitte nøkler for sensitive dokumenter (mindre skadeomfang), og roter nøklene når brukere slutter. Haven Enterprise legger fjernsletting på enheten med admin-signatur til de samme governance-policyene: tenanten fjernes fra en stjålet eller forlatt enhet neste gang den kobler seg til.

Flere nøkler per bruker (signering, kryptering, navngitte symmetriske nøkler) må distribueres sikkert. Mottiltak: ett enkelt passord låser opp alle nøkler via PBKDF2 med ulike salt. KeyBag gir én samlet nøkkellagring. Flyten med tilkoblingsforespørsel og -svar håndterer nøkkelutvekslingen for nye brukere. Haven Enterprise automatiserer det løpende arbeidet: admin-signerte policyer for nøkkeldistribusjon forsyner brukere og grupper med nøkler — og tilbakekaller dem igjen — pakket per mottaker, og hver klient avstemmer sin KeyBag ved neste synkronisering.

Som standard kan serveren ikke spørre mot dokumentinnhold, fordi den bare ser chiffertekst. All spørring skjer på klientsiden gjennom inkrementell indeksering. Men trenger bruksområdet ditt behandling på serversiden (for eksempel et bookingsystem på nett eller et offentlig nettsted), kan du gi serverprosessen en dekrypteringsnøkkel eller dele en del av dataene med den. Det er et bevisst arkitekturvalg per installasjon — standarden er konfidensialitet, og servertilgang kommer bare til der du selv slår den på.

En omfattende sikkerhetsrevisjon pekte ut områder som bør herdes: rate limiting på endepunktene, tilbakekalling av JWT-tokens og rotasjon av admin-nøkkelen. Tilbakedaterte endringer fra tilbakekalte brukere hindres nå av vitnekvitteringer med betrodd tid (se modellen for tilgangskontroll). Det kryptografiske fundamentet (Ed25519, AES-256-GCM, RSA-OAEP) er solid. Den operative herdingen er i gang.