Oblasť kryptografie pracujúca s dvomi typmi kľúčov, verejnými a súkromnými.
Infraštruktúra a postupy spravovania a distribúcie verejných kľúčov pomocou certifikátov a autorít.
Kryptografická konštrukcia schopná dokázať identitu vlastníka súkromného kľúča.
Člen hierarchie PKI, ktorý ručí za ním podpísané certifikáty a teda za identitu vlastníkov kľúčov, na ktoré sa dané certifikáty viažu. Ak veríme konkrétnej autorite, veríme aj všetkým entitám, ktorým verí daná autorita.
Vzniká, keď certifikačná autorita podpíše kľúč inej certifikačnej autority. Certifikát je dôveryhodný, ak je dôveryhodná autorita, ktorá zaň ručí. Za dôveryhodné autority, ktoré ručia za seba ručí admin systému.
Štandard pre certifikáty je X.509. Certifikát vzniká podpísaním žiadosti o certifikát (Certificate Signing Request) certifikačnou autoritou, nie nutne rozdielnou od žiadajúcej entity. Žiadosť musí obsahovať identitu vlastníka kľúča, parametre kľuča a musí byť podpísaná daným kľúčom. Pri podpisovaní certifikačnou autoritou sa dodá id certifikátu a iné metadata. Identita pozostáva zo štvorice Organization name (O), Organization Unit (OU), Common Name (CN) a email.
Pre inštaláciu certifikátov sa historicky používal zoznam/directory dôveryhodných certifikátov, avšak v dnešných systémoch je takýchto zoznamov niekoľko a teda je lepšie používať nástroje, ktoré tento proces uľahčujú. Jedno z takýchto riešení je p11-kit (Fedora, Arch), ktorý je schopný inštalovať certifikáty system-wide, udržovať samostatné databázy certifikátov pre userov alebo blacklistovať certifikáty. Pre globálnu inštaláciu certifikátu stačí spustiť ako root
trust anchor --store FILE.crt
Debian based systémy používajú spooling directory /usr/share/local/ca-certificates a update-ca-certificates(8). Pre overenie, či systém dôveruje danému certifikátu, môžeme použiť openssl-verify(1)
Na prevádzkovanie služieb (intermediate) CA potrebujeme byť schopný podpisovať (a vytvárať) žiadosti o certifikáty a revokovať certifikáty. Na prácu s certifikátmi existuje niekoľko GUI (TinyCA, Xca, SimpleAuthority) a CLI (pki(1), OpenSSL) nástrojov.
Ak chceme žiadať o certifikát, potrebujeme najskôr kľúč. Takto vygenerujeme RSA súkromný kľúč s daným exponentom do súboru FILE.key.
openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_pubexp:65537 -out FILE.key
Pre daný kľúč vygenerujeme CSR s typom podpisu sha512.
openssl req -new -sha512 -key FILE.key -out FILE.csr
Ak generujeme veľa žiadostí môžeme namiesto interaktívneho -new poslať do programu súbor prepínačom -in. Príklad takého súboru z dokumentácie
CN=My Name OU=My Organization emailAddress=someone@somewher.org
Keď máme vytvorenú žiadosť, môžeme overiť jej parametre pomocou
openssl req -text -in FILE.csr
Pre podpisovanie CSR môžeme použiť openssl-ca(1), avšak pred jej použitím je vhodné overiť OpenSSL nastavenia alebo použiť prepínač -config pre načítanie nastavení zo súboru.
openssl ca -config FILE.conf -in FILE.csr -out FILE.crt
Príklad FILE.conf z článku Stefana Magnusa Landrø.
[ ca ] default_ca = ca_default [ ca_default ] dir = ./ca certs = $dir new_certs_dir = $dir/ca.db.certs database = $dir/ca.db.index serial = $dir/ca.db.serial RANDFILE = $dir/ca.db.rand certificate = $dir/ca.crt private_key = $dir/ca.key default_days = 365 default_crl_days = 30 default_md = md5 preserve = no policy = generic_policy [ generic_policy ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = optional emailAddress = optional
Pre ochranu pred negatívnym dopadom stratených súkromnýmch kľúčov musí byť CA schopná certifikáty pre takéto kľúče zneplatniť. Dnes sa na to používa CRL (Certificate Revocation List, periodicky obnovovaný) alebo OCSP (Online Certificate Status Protocol, on-demand). OpenSSL podporuje CRL príkazom
openssl ca -revoke FILE.crt
DNS-based Authentication of Named Entities je protokol, ktorého myšlienka spočíva v distribuovaní certifikátov pomocou DNS serverov, ktoré čiastočne nahrádzajú CA. Toto dáva domain adminom väčšiu kontrolu nad relevantnými certifikátmi. Kryptografickú bezpečnosť musí zaručiť DNSSEC
Je model spravovania certifikátov bez hierarchie. Každý použivateľ sa môže podpísať ako ručiteľ certifikátu. Decentralizovaný model má mnoho výhod, najmä absenciu single point of failure, avšak prenáša veľa zodpovednosti na koncového použivateľa.