{"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://cmaintz.github.io/tech-atlas/)"},"id":"cs/key-management","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/key-management/","da":"https://cmaintz.github.io/tech-atlas/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."},"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}