{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"cs/key-management","url":{"en":"https://atlas.maintz.dev/en/terms/cs/key-management/","da":"https://atlas.maintz.dev/da/terms/cs/key-management/"},"term":{"en":"Key management","da":"Nøglehåndtering"},"aka":{"en":["cryptographic key management"],"da":["håndtering af kryptografiske nøgler"]},"domain":["cs"],"cluster":"cryptography","layer":"theory","status":"current","summary":{"en":"Looking after cryptographic keys over their whole life - making, storing, handing out, changing and finally destroying them.","da":"At passe på kryptografiske nøgler gennem hele deres levetid - at skabe, gemme, udlevere, skifte og til sidst destruere dem."},"body":{"formal":{"en":"The rules, roles and tools that govern each stage of a key's life - creation from a good random source, protected storage, controlled sharing and use, planned replacement, cancelling a leaked key and destroying retired ones - including who may do each step.","da":"De regler, roller og værktøjer, der styrer hvert trin i en nøgles liv - skabelse fra en god tilfældighedskilde, beskyttet opbevaring, kontrolleret deling og brug, planlagt udskiftning, tilbagekaldelse af en lækket nøgle og destruktion af nøgler, der er taget ud af brug - herunder hvem der må udføre hvert trin."},"plain":{"en":"Like a building manager's key cabinet - keys are cut, numbered, signed out, changed when a tenant moves and melted down when a lock is replaced.","da":"Som viceværtens nøgleskab - nøgler bliver lavet, nummereret, kvitteret for, skiftet, når en lejer flytter, og smeltet om, når en lås udskiftes."},"inPractice":{"en":"The IT security manager at a pension fund keeps its signing keys in sealed hardware that never lets them out, replaces them every year on a set date, and has a written plan for what to do if one is exposed.","da":"IT-sikkerhedschefen i en pensionskasse opbevarer signeringsnøglerne i forseglet hardware, der aldrig slipper dem ud, skifter dem hvert år på en fast dato og har en skriftlig plan for, hvad der skal ske, hvis én bliver afsløret."},"whyItMatters":{"en":"Strong encryption fails the moment a key is stolen, lost or kept in use for too long, and most real failures come from careless handling of keys rather than from weak maths.","da":"Stærk kryptering svigter i det øjeblik, en nøgle bliver stjålet, mistet eller brugt for længe, og de fleste virkelige svigt skyldes sjusket håndtering af nøgler snarere end svag matematik."}},"deepDive":{"en":"The reference framework is NIST SP 800-57 Part 1 Rev. 5 (May 2020). It models a key as moving through states such as pre-activation, active, suspended, deactivated, compromised and destroyed, and ties each transition to an authorised action. Central to it is the cryptoperiod: the time span during which a key may be used, split for symmetric keys into an originator-usage period (when it may protect new data) and a recipient-usage period (when it may still decrypt or verify old data). Cryptoperiods are chosen from the algorithm's strength, the volume of data protected, the exposure of the key and the cost of re-keying, not from a fixed calendar rule.\n\nArchitecturally, almost every large system uses a key hierarchy with envelope encryption. Data is encrypted with data-encryption keys (DEKs), which are stored alongside the data only in wrapped form, encrypted under a key-encryption key (KEK) that never leaves a hardware security module or cloud KMS. Rotating the KEK then means re-wrapping small DEKs rather than re-encrypting terabytes, and destroying a KEK renders all data under it unrecoverable, which is the basis of crypto-shredding for deletion. HSMs are validated under FIPS 140-3 (security levels 1 to 4, levels 3 and 4 adding physical tamper response and identity-based authentication), and applications reach them through PKCS#11, KMIP (OASIS) or a cloud provider API. Cloud variants range from provider-managed keys through customer-managed keys to BYOK and hold-your-own-key models, differing in who can technically use the key, which matters for GDPR transfer assessments and sovereignty requirements.\n\nControls for high-value keys include split knowledge and dual control (no single person can reconstruct or use the key, often implemented as M-of-N key shares, for example with Shamir secret sharing), documented key ceremonies with witnesses and video for CA root keys, separation of the key custodian role from system administration, and tamper-evident audit logs of every use. Backup and escrow must be designed explicitly: a signing key should generally not be escrowed, since copies weaken non-repudiation, whereas a decryption key for archived data must be recoverable or the data is lost.\n\nAudits usually map these practices to ISO/IEC 27001:2022 Annex A control 8.24 (use of cryptography), which expects rules for the whole key life cycle, and to PCI DSS requirement 3 for cardholder data. Frequent real-world failures are keys hard-coded in source code or container images, keys stored on the same host or volume as the data they protect, no inventory of which keys and certificates exist (so nobody notices when one expires or leaks), and no tested procedure for emergency rotation. The post-quantum migration has made a cryptographic inventory a key-management task in its own right. Key management is broader than secrets management: the latter stores and distributes credentials to workloads, while key management governs generation, strength, lifetime and destruction.","da":"Referencerammen er NIST SP 800-57 Part 1 Rev. 5 (maj 2020). Den beskriver en nøgles liv som en række tilstande, fx pre-activation, active, suspended, deactivated, compromised og destroyed, og knytter hver overgang til en autoriseret handling. Centralt står kryptoperioden: det tidsrum, hvor en nøgle må bruges, som for symmetriske nøgler deles i en periode, hvor den må beskytte nye data, og en periode, hvor den stadig må dekryptere eller verificere gamle data. Kryptoperioder vælges ud fra algoritmens styrke, mængden af beskyttede data, nøglens eksponering og omkostningen ved nøgleskift, ikke ud fra en fast kalenderregel.\n\nArkitektonisk bruger næsten alle større systemer et nøglehierarki med envelope encryption. Data krypteres med datakrypteringsnøgler (DEK), som kun gemmes sammen med data i indpakket form, krypteret under en nøglekrypteringsnøgle (KEK), der aldrig forlader et hardwaresikkerhedsmodul (HSM) eller en cloud-KMS. At skifte KEK betyder så at pakke små DEK'er om i stedet for at genkryptere terabytes, og destruktion af en KEK gør alle data under den uoprettelige, hvilket er grundlaget for crypto-shredding ved sletning. HSM'er valideres efter FIPS 140-3 (sikkerhedsniveau 1 til 4, hvor niveau 3 og 4 tilføjer fysisk reaktion på manipulation og identitetsbaseret autentificering), og applikationer tilgår dem via PKCS#11, KMIP (OASIS) eller en cloududbyders API. I cloud spænder varianterne fra udbyderstyrede nøgler over kundestyrede nøgler til BYOK og hold-your-own-key, og forskellen på, hvem der teknisk kan bruge nøglen, har betydning for vurderinger af overførsler efter databeskyttelsesforordningen og for krav om suverænitet.\n\nKontroller for særligt værdifulde nøgler omfatter delt viden og dobbeltkontrol (ingen enkeltperson kan genskabe eller bruge nøglen, ofte implementeret som M-af-N-nøgleandele, fx med Shamirs secret sharing), dokumenterede nøgleceremonier med vidner og video for CA-rodnøgler, adskillelse af nøgleforvalterrollen fra systemadministration og manipulationssikre auditlogs over al brug. Backup og deponering skal designes bevidst: en signeringsnøgle bør som regel ikke deponeres, da kopier svækker uafviseligheden, mens en dekrypteringsnøgle til arkiverede data skal kunne genskabes, ellers er data tabt.\n\nRevisioner kobler typisk denne praksis til ISO/IEC 27001:2022 Annex A kontrol 8.24 (brug af kryptografi), som forventer regler for hele nøglens livscyklus, og til PCI DSS krav 3 for kortholderdata. Hyppige fejl i praksis er nøgler hardkodet i kildekode eller containerimages, nøgler lagret på samme vært eller volumen som de data, de beskytter, manglende overblik over hvilke nøgler og certifikater der findes (så ingen opdager, når ét udløber eller lækker), og ingen afprøvet procedure for nødudskiftning. Overgangen til post-kvante-algoritmer har gjort en kryptografisk fortegnelse til en selvstændig nøglehåndteringsopgave. Nøglehåndtering er bredere end håndtering af hemmeligheder: sidstnævnte gemmer og udleverer legitimationsoplysninger til workloads, mens nøglehåndtering styrer generering, styrke, levetid og destruktion."},"howTo":{"steps":{"en":["Build an inventory of all keys and certificates - encryption keys, signing keys, TLS and SSH keys, API keys and HSM or KMS keys - with owner, purpose, algorithm, location and expiry date.","Write a key management policy that sets the approved algorithms and key lengths, a cryptoperiod for each key type, who may create, use and destroy keys, and how often each key is rotated.","Move keys into a hardware security module or cloud KMS, generate them there from a strong random source, and remove keys from source code, configuration files and container images.","Use envelope encryption, where data keys are wrapped by a master key that never leaves the KMS or HSM, and give applications permission only to use a key, not to export or delete it.","Require dual control or split knowledge for the most valuable keys, such as root CA and master keys, and document every key ceremony with witnesses and logs.","Turn on automatic rotation where the platform supports it, and back up decryption keys for archived data in a separate, protected place, while signing keys are not escrowed.","Write and test a procedure for a leaked key - revoke it, issue a new one, re-encrypt or re-sign what is needed and tell those affected - at least once a year.","Log all key use and administration, alert on unusual use and on keys close to expiry, and destroy retired keys in a documented way once no data depends on them."],"da":["Lav en oversigt over alle nøgler og certifikater - krypteringsnøgler, signeringsnøgler, TLS- og SSH-nøgler, API-nøgler og nøgler i HSM eller KMS - med ejer, formål, algoritme, placering og udløbsdato.","Skriv en politik for nøglehåndtering, der fastsætter godkendte algoritmer og nøglelængder, en kryptoperiode for hver nøgletype, hvem der må oprette, bruge og destruere nøgler, og hvor ofte hver nøgle skiftes.","Flyt nøglerne ind i et hardware security module eller en cloud-KMS, generér dem dér fra en stærk tilfældighedskilde, og fjern nøgler fra kildekode, konfigurationsfiler og container-images.","Brug envelope encryption, hvor datanøgler er pakket ind i en hovednøgle, der aldrig forlader KMS eller HSM, og giv kun applikationer ret til at bruge en nøgle, ikke til at eksportere eller slette den.","Kræv dobbeltkontrol eller delt viden for de mest værdifulde nøgler, fx rod-CA- og hovednøgler, og dokumentér hver nøgleceremoni med vidner og log.","Slå automatisk nøgleskift til, hvor platformen understøtter det, og tag backup af dekrypteringsnøgler til arkiverede data et separat, beskyttet sted, mens signeringsnøgler ikke deponeres.","Skriv og afprøv mindst en gang om året en procedure for en lækket nøgle - tilbagekald den, udsted en ny, genkryptér eller gensignér det nødvendige, og underret de berørte.","Log al brug og administration af nøgler, alarmér ved usædvanlig brug og ved nøgler, der snart udløber, og destruér udfasede nøgler på en dokumenteret måde, når ingen data længere afhænger af dem."]},"pitfalls":{"en":["Keeping keys on the same server or in the same repository as the data or code they protect.","Having no list of keys and certificates, so nobody notices when one expires or leaks until a service stops working.","Destroying or rotating away a key while backups or archives still depend on it, which makes that data unreadable for good."],"da":["At opbevare nøgler på samme server eller i samme kodearkiv som de data eller den kode, de beskytter.","Ikke at have en liste over nøgler og certifikater, så ingen opdager, at en udløber eller er lækket, før en tjeneste holder op med at virke.","At destruere eller udskifte en nøgle, mens backup eller arkiver stadig afhænger af den, så de data bliver ulæselige for altid."]},"guides":[{"title":"NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management","url":"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final","publisher":"NIST","tier":"standard"},{"title":"Key Management Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"Key rotation - Cloud Key Management Service","url":"https://docs.cloud.google.com/kms/docs/key-rotation","publisher":"Google","tier":"official-doc"},{"title":"Overgangen til kvantesikker kryptografi","url":"https://samsik.dk/cybersikkerhed/temaer/overgangen-til-kvantesikker-kryptografi/","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"}]},"edges":[{"type":"requires","to":"cs/cryptographic-key","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/encryption","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/data-breach","why":{"en":"Keys that are kept apart from the data, changed often and cancelled quickly when leaked limit how much a thief can read.","da":"Nøgler, der holdes adskilt fra data, skiftes ofte og tilbagekaldes hurtigt ved læk, begrænser, hvor meget en tyv kan læse."},"confidence":"medium","strength":"normal"},{"type":"used-with","to":"platform/secrets-management","why":{"en":"Secrets management stores and hands out keys to programs; key management sets the rules for how those keys are made, changed and retired.","da":"Håndtering af hemmeligheder gemmer og udleverer nøgler til programmer; nøglehåndtering fastsætter reglerne for, hvordan nøglerne skabes, skiftes og udfases."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/public-key-infrastructure","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management","url":"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final","tier":"standard","publisher":"NIST"}],"draft":true}