# Kryptering ## Hvad det er Kryptering omdanner læsbare data, klarteksten, til chiffertekst ved at køre dem gennem en offentlig algoritme sammen med en hemmelig værdi, en nøgle. Med den rigtige nøgle giver dekrypteringen klarteksten tilbage byte for byte. At algoritmen er offentlig, er med vilje: AES, som de fleste systemer bruger, vandt en åben konkurrence hos NIST i 2000 og er udgivet som en gratis standard. Krypteringen hviler alene på, at nøglen holdes hemmelig. Algoritmerne falder i to familier. En symmetrisk algoritme bruger den samme nøgle begge veje. AES, specificeret i FIPS 197, krypterer data i blokke på 128 bit med en nøgle på 128, 192 eller 256 bit. ChaCha20 fra RFC 8439 krypterer en strøm af data og er omkring tre gange så hurtig som AES på hardware uden særlige AES-instruktioner. Symmetrisk kryptering er hurtig nok til en hel disk, men begge ender skal have den samme nøgle, og det svære er at få den sikkert frem. Kryptografi med offentlige nøgler løser det med et nøglepar, hvor den ene nøgle offentliggøres og den anden holdes privat. To parter kan hver især kombinere deres private nøgle med den andens offentlige og nå den samme fælles hemmelighed uden at sende den. Den slags beregninger er langsomme, så rigtige systemer bruger begge dele: en udveksling med offentlige nøgler aftaler en frisk symmetrisk nøgle, og den symmetriske algoritme bærer dataene. TLS, protokollen bag hver `https://`-adresse, arbejder sådan. Den vigtigste moderne idé er autentificering. En ren krypteringsalgoritme skjuler indholdet, men lader det stå åbent for ændringer: i tællertilstand (counter mode) vender en ændret bit i chifferteksten den samme bit i klarteksten, og modtageren dekrypterer den ændrede besked, som var den ægte. Autentificeret kryptering med tilknyttede data, AEAD, tilføjer et mærke (tag), som modtageren tjekker, før den stoler på en eneste byte. AES-GCM og ChaCha20-Poly1305 er det almindelige par, og TLS 1.3, udgivet som RFC 8446 i 2018, beholdt kun AEAD-algoritmer og gav enhver nøgleudveksling med offentlige nøgler forward secrecy, så en servernøgle, der stjæles senere, åbner ingen optagne sessioner. ## Hvorfor det betyder noget Data bliver sjældent på hardware, ejeren selv styrer; de krydser andres netværk og ligger i andres datacentre. Kryptering er det, der lader dem passere de steder sikkert: en stjålet disk, et aflyttet kabel eller en lækket bucket giver chiffertekst, og chiffertekst uden nøglen er støj. Det flytter problemet i stedet for at fjerne det: når data er krypteret, er deres sikkerhed nøglens sikkerhed. NIST's anbefaling om nøglehåndtering, SP 800-57, sammenligner nøgler med kombinationen til et pengeskab: en modstander, der kender kombinationen, går lige forbi det stærkeste pengeskab, og dårlig nøglehåndtering kan let undergrave en stærk algoritme. Det meste af det egentlige arbejde er derfor nøglearbejde: at gemme nøgler adskilt fra dataene, begrænse, hvor meget hver enkelt beskytter, udskifte dem efter en plan og vogte reservekopien lige så nøje som originalen. Lovgiverne trækker den samme linje. Databeskyttelsesforordningen nævner pseudonymisering og kryptering af personoplysninger blandt sikkerhedsforanstaltningerne i artikel 32. Artikel 34 fritager en dataansvarlig fra at underrette hver berørt person om et brud, når de lækkede oplysninger var uforståelige for enhver uden autoriseret adgang, og kryptering er det eksempel, artiklen giver. Kryptering under transport, mest TLS, beskytter data på ledningen, og kryptering i hvile beskytter dem på lager. Selve brugen ligger uden for begge: en server, der dekrypterer en post for at arbejde med den, har klarteksten og nøglen på samme tid, så den, der styrer serveren, læser det samme som den. ## Sådan ser det ud i praksis Under transport er det daglige arbejde at holde certifikaterne gyldige. Da [hundrede Docker-applikationer havde brug for SSL/TLS-certifikater](/da/portfolio/automated-ssl-tls-certificate-creation-for-100-docker-41/), oprettede et ACME-workflow hvert certifikat, fornyede det, før det udløb, og udrullede det til Ubuntu-værter med Apache og Nginx. Målet var at tage mennesket ud af løkken, for mennesket er den del, der glemmer, og et udløbet certifikat tager en app ned lige så sikkert som en knækket algoritme. I hvile er det nyttige spørgsmål, hvem der har nøglen. Før virksomheden byggede [krypterede sikkerhedskopier uden for værten med en månedlig gendannelsesøvelse](/da/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/), var et udbydersnapshot hele gendannelsespositionen. Det lå i den samme konto som den maskine, det beskyttede, og var ikke krypteret af nogen her. Den nye løsning bruger restic, som krypterer alt, hvad det gemmer, med AES-256 i tællertilstand og autentificerer det med Poly1305-AES, før det forlader værten over SFTP. Lageret står hos en anden udbyder, som dermed har chifferteksten, mens virksomheden har adgangssætningen. Selv adgangssætningens vej ind i programmet betød noget. Den læses fra en fil, for supervisoren behandler undvigetegn i miljøværdier: rummede adgangssætningen en omvendt skråstreg, ville den tavst være blevet ændret på vejen, og restic ville have fået en anden adgangssætning end den, backuplageret blev oprettet med. Hver måned gendanner en øvelse en fil med kendt indhold og sammenligner den, og da gendannelsen ikke kan ske uden adgangssætningen, beviser hver øvelse også, at nøglen stadig åbner dataene. Da platformen var ved at få en vært mere, afgjorde det samme ræsonnement, hvordan [hver driftshemmelighed blev delt per vært](/da/portfolio/split-every-operational-secret-per-host-125/). En repositorystreng er kun en placering; adgangssætningen er hele krypteringen. To værter, der deler én adgangssætning, er ét backuplager med to kataloger i sig, og et læk fra den ene åbner begge. Hver hemmelighed blev til et opslag med værten som nøgle, og argumentet står ved siden af konfigurationen. SP 800-57 siger det generelt: at begrænse, hvad én nøgle beskytter, begrænser skaden, når den lækker. ## Hvor det går galt **Nøglen findes ét sted.** En stærk algoritme behandler en ejer, der har glemt adgangskoden, nøjagtig som en angriber. Dokumentationen til restic siger det ligeud: mister man adgangskoden, er dataene tabt for altid. Ethvert krypteret lager har brug for en ekstra kopi af sin nøgle, opbevaret uden for rækkevidde af det, der ødelægger den første. **Nøglen ligger ved siden af dataene.** En database, der er krypteret med en nøgle i den samme servers konfiguration, eller en sikkerhedskopi, hvis adgangssætning ligger i den samme bucket, stopper kun en tyv, der tager halvdelen af filerne. Diskkryptering er den stille udgave: den beskytter et drev, der tages ud af en slukket maskine, mens en kørende server allerede har låst sin disk op, og en angriber på den server læser klartekst. **Hemmeligholdelse forveksles med integritet.** Et system bygget på en ren krypteringstilstand skjuler indholdet og lader stadig en angriber ændre det. Brug en AEAD-konstruktion, og kassér enhver besked, hvis mærke ikke stemmer, før der handles på en eneste byte af den. **En nonce gentages.** AES-GCM og ChaCha20-Poly1305 tager en nonce, en værdi, der skal være unik for hver besked under den samme nøgle. RFC 8439 kalder det den vigtigste sikkerhedsovervejelse: to beskeder med samme nonce deler nøglestrøm og engangsnøgle til autentificering, og det afslører XOR af de to klartekster. En tæller er en sikker måde at lave nonces på, så længe én tæller ejer nøglen: to processer, der deler en nøgle og hver tæller fra nul, giver netop den gentagelse, RFC'en advarer imod. **En adgangskode bruges som nøgle.** Mennesker vælger adgangskoder; algoritmer kræver tilfældige nøgler af fast længde. En adgangssætning skal først gennem en nøgleafledningsfunktion, sådan som restic gør med scrypt, som RFC 7914 gør hukommelseskrævende, så massegætning på specialhardware forbliver dyr. Gemte login-adgangskoder er et særskilt tilfælde: de hører hjemme i sådan en funktion som hashværdier, for en server, der kan dekryptere dem, kan også lække dem. **Metadata forbliver synlige.** Kryptering skjuler indhold, mens størrelse, timing og adresserne i begge ender stadig kan ses. TLS 1.3 lader en afsender tilføje fyld (padding) for at skjule, hvor store beskederne er, og fyldet er valgfrit, så længden siger ofte mere, end ejeren regner med. ## Læs mere - [NIST Glossary: encryption](https://csrc.nist.gov/glossary/term/encryption) — NIST's definitioner af begrebet, hver med sin kilde. - [FIPS 197: Advanced Encryption Standard (AES)](https://csrc.nist.gov/pubs/fips/197/final) — AES-specifikationen med blokstørrelse og nøglelængder. - [NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) — hvordan nøgler laves, gemmes, bruges og udfases, og hvad et læk betyder. - [RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446) — protokollen bag `https://`, med AEAD-beskyttelse og forward secrecy. - [RFC 8439: ChaCha20 and Poly1305 for IETF Protocols](https://www.rfc-editor.org/rfc/rfc8439) — strømalgoritmen, autentificeringen og deres AEAD-kombination, med reglerne for nonces. - [restic: References](https://restic.readthedocs.io/en/stable/100_references.html) — hvordan et backupværktøj afleder nøgler fra en adgangskode og krypterer og autentificerer sine data.