| PKCS#12 | |
|---|---|
| Rozšíření | .p12[1] nebo [1].pfx |
| MIME typ | application/x-pkcs12 [1] |
| Vývojář | RSA Security [d] |
| zveřejněno | 1996 |
| Poslední vydání |
PKCS #12 v1.0 (24. června 1999 Technical Corrigendum 1 / 25. února 2000 ) |
| Typ formátu | Archiv |
| Obsahuje | Certifikáty veřejného klíče X.509 , soukromé klíče X.509 , X.509 CRL , obecná data |
| Rozšířeno z | Formát souborů Microsoft PFX |
V kryptografii je PKCS#12 jedním ze standardů kryptografie s veřejným klíčem (PKCS) publikovaným společností RSA Laboratories . Definuje formát souboru používaný k uložení a/nebo přenosu soukromého klíče ( en:Private key ), řetěz důvěryhodnosti od certifikátu uživatele ke kořenovému certifikátu CA a seznam odvolaných certifikátů (CRL). Soubor je chráněn jedním ze dvou způsobů: zabezpečeným pomocí důvěryhodného páru klíčů (veřejné/soukromé klíče vhodné pro digitální podepisování a šifrování) nebo méně zabezpečeným pomocí symetrického klíče založeného na hesle . Druhý je vhodný pro případy, kdy není k dispozici použití důvěryhodných párů veřejného/soukromého klíče. Formát PKCS#12 je formát určený k uložení páru klíčů (soukromý klíč a certifikát), který je rozpoznán a používán mnoha prohlížeči a poštovními agenty. Soubory PKCS#12 uchovávají certifikát i soukromý klíč (samozřejmě v zašifrované podobě). Příklad organizace souborů PKCS#12 je znázorněn na obrázku vpravo.
Tato norma popisuje syntaxi pro přenos osobních identifikačních informací, včetně soukromých klíčů, certifikátů, různých tajemství a dalších. Tento standard podporuje přímý přenos dat mezi odesílající platformou a přijímající platformou. Standard podporuje přenos dat jak s vysokou úrovní ochrany (pomocí páru veřejného/soukromého klíče používaného pro digitální podpis a šifrování), tak s nižší úrovní ochrany (pomocí autorizace heslem), v případě, že použití veřejného klíč /private key není k dispozici.
Standard je implementován jak hardwarově, tak softwarově. Příkladem hardwarové implementace jsou bezpečné tokeny jako Smart Card a PC Card .
Tento standard lze považovat za rozšíření standardu PKCS8 . Součástí jsou další identifikační informace, včetně soukromých klíčů. Zavedl režim vysokého zabezpečení skrytím veřejného klíče.
Před několika lety byly kryptografické systémy používány pouze ve výjimečných případech: ve vládních organizacích, zpravodajských agenturách a dalších systémech kritických pro bezpečnost dat. V současné době však rychlý rozvoj počítačových sítí a internetu nutí stále více lidí přemýšlet o bezpečnosti. V dnešní době se každý zajímá o bezpečnost dat přenášených po síti. V důsledku toho se objevilo mnoho různých certifikátů a metod šifrování . Tento článek se bude zabývat formátem úložiště klíčů PKCS#12 a některými problémy spojenými s bezpečným ukládáním soukromých klíčů certifikátu.
V průběhu let bylo kromě původních formátů PKCS5 a PKCS8 vytvořeno velké množství formátů úložiště , které byly omezeny na DES a MD5 . To vedlo k šíření nekompatibilních a často nezabezpečených formátů úložiště soukromých klíčů. To vyvrcholilo extrémně složitým formátem PKCS12 se směsí nekompatibilních identifikátorů objektů, algoritmů, obsahu dat a požadavků na zpracování. V důsledku tohoto zmatku byla implementace jak nejistá, tak nekompatibilní se staršími verzemi. Protože požadavky neposkytovaly dostatek informací pro implementaci kompatibilních verzí. Dalším problémem s tímto formátem byla data bloat, která jej učinila nepoužitelným pro použití v zařízeních s omezenou pamětí, jako jsou čipové karty .
Tyto změny zdůraznily potřebu zjednodušení, zabezpečení a interoperability formátů úložiště soukromých klíčů. Úkoly vývojářů pro tento formát byly následující:
PKCS#12 je nástupcem „PFX“ od společnosti Microsoft . Termíny „soubor PKCS#12“ a „soubor PFX“ se někdy používají zaměnitelně.
PFX byl těžce kritizován za to, že je jedním z nejsložitějších kryptografických protokolů, přesto zůstává dnes jediným standardním způsobem, jak uložit soukromé klíče a certifikáty v jediném zašifrovaném souboru.
Netscape používal formát PFX spíše než PKCS#12 ve verzích 4.03 a nižších, protože formát PKCS#12 prostě neexistoval. Kvůli potřebě zpětné kompatibility podporoval Netscape 4.04 a novější a všechny verze MSIE pouze importy PFX. Níže uvedená tabulka shrnuje výše uvedené.
| Software | import PKCS#12 | export PKCS#12 | PFX import | Export PFX |
|---|---|---|---|---|
| Netscape 4.03 a starší | Ano. | Ano. | Ano. | Ano. |
| Netscape 4.04 a novější | Ano. | Ano. | Ano. | Ano. |
| MSIE 4.0 a novější | Ano. | Ano. | Ano. | Ano. |
SD
V tomto standardu je povolena jakákoli kombinace režimů ochrany soukromí a spravedlnosti. Dobrá bezpečnostní politika samozřejmě zahrnuje vyhýbání se určitým praktikám. Bylo by například pošetilé přenášet soukromý klíč bez jakékoli fyzické ochrany.
Pro oba režimy (důvěrnost a poctivost) je vhodnější použít veřejný klíč než heslo. Ne vždy je však možné použít režim pomocí veřejného klíče. Například pokud v době odeslání neznáme dostatek informací o platformě příjemce. V tomto případě bude režim využívající veřejný klíč pouze rušit.
Pár soukromý/veřejný klíč se skládá ze dvou sad parametrů. Veřejná nastavení s dalšími identifikačními informacemi, jako jsou uživatelská jména a e-mailové adresy, jsou uložena nešifrovaná. Soukromé možnosti jsou většinou uloženy pomocí nějakého ochranného mechanismu, jako je šifrování.
Formát kontejneru byl definován na základě formátu implementovaného v PKCS#7 a S/MIME . Následující identifikátor objektu identifikuje typ zabezpečeného úložiště obsahu soukromého klíče.
id-securedPrivateKey IDENTIFIKÁTOR OBJEKTU ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 42 }Typ zabezpečeného úložiště obsahu soukromého klíče musí být typu ASN.1 SecuredPrivateKey :
SecuredPrivateKey ::= SEQUENCE { verze Verze, veřejný klíč, privateKey ContentInfo }Pole typu SecuredPrivateKey mají následující význam:
verze – číslo verze syntaxe, musí být 0.
publicKey – Veřejná složka klíče a další identifikační informace o vlastníkovi klíče.
privateKey je zabezpečený soukromý klíč skládající se z identifikátoru typu obsahu a samotného obsahu.
Komponenty veřejného klíče jsou uloženy v nešifrované podobě. Děje se tak proto, že neexistuje dostatečný důvod pro šifrování těchto dat. Protože šifrování těchto dat pomocí libovolné proudové šifry vystavuje útočníka značnému množství známého šifrovaného textu a protože musí mít uživatel možnost získat přístup ke svému veřejnému klíči, aniž by byl vyzván k zadání hesla. Informace o veřejném klíči jsou reprezentovány typem PublicKeyInfo :
PublicKeyInfo ::= CHOICE { publicKeyInfo SubjectPublicKeyInfo, -- Nezpracované informace o veřejném klíči certRequest [ 0 ] EXPLICITNÍ PKCS10CertRequest, -- PKCS #10 cert.req. certifikát [ 1 ] EXPLICITNÍ Certifikát, -- certifikát X.509 certChain [ 2 ] EXPLICITNÍ PKCS7CertChain – PKCS #7 cert.chain }Ve své nejjednodušší podobě je veřejný klíč uložen jako SubjectPublicKeyInfo . Jakmile je vygenerována žádost o certifikaci, lze „nezpracované“ informace o veřejném klíči podle potřeby nahradit a když je klíč certifikován, lze uložit buď certifikát, nebo šifru úplného certifikátu.
Komponenty soukromého klíče mohou být uloženy v zašifrované nebo nešifrované formě. Zašifrovaná forma se doporučuje, pokud data nejsou chráněna jinými prostředky. Pokud jsou data uložena v nešifrované podobě, použije se typ obsahu dat . Pokud jsou data uložena v zašifrované podobě, použije se typ EncryptedData s contentEncryptionAlgorithm - šifrovacím algoritmem, režimem a dalšími parametry, které se používají při generování klíče. Obsah nebo zašifrovaný obsah polí soukromého klíče (bez odpovídajících polí veřejného klíče), které odpovídají polím veřejného klíče uvedeným v PublicKeyInfo.
Například pro RSA :
RSAPrivateKey ::= SEQUENCE { privateExponent INTEGER, -- Private Exponent d prvočíslo1 INTEGER, -- Prvočinitel p z n prime2 INTEGER, -- Prvočinitel q z n exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) koeficient INTEGER—CRT koeficient (q^-1) mod } DSAPrivateKey ::= SEQUENCE { x INTEGER – soukromé náhodné celé číslo }Důvody, proč jsou uložena pouze pole soukromého klíče, jsou: za prvé, aby se zabránilo redundanci (vše ostatní je již obsaženo v PublicKeyInfo); za druhé, aby se eliminovala možnost triviálního obnovení významného součtu toku klíčů pomocí známých veřejných polí na začátku klíče.
PKCS#12 podporuje následující šifrovací algoritmy:
Kromě toho je podporován také režim PKCS#5 v1.5 . To vám umožní používat následující algoritmy:
Použití PKCS#5 v2.0 umožní použití libovolného šifrovacího algoritmu.
OpenSSL dokáže zpracovat PKCS#5 v1.5 a v2.0 v souborech PKCS#12, ale jiné implementace nejsou podporovány.
Následující tabulka shrnuje podporu pro různá šifrování:
| Software a režim. | Šifrování certifikátu | Šifrování privátním klíčem |
|---|---|---|
| MSIE4 (domácí a exportní verze) export PKCS#12. | 40bitový RC2 . | 40bitový RC2 . |
| MSIE4, 5 (domácí a exportní verze) PKCS#12 import. | 40 bit RC2 , 3 klíč 3DES . | 40 bit RC2 , 3 klíč 3DES . |
| Export MSIE5 PKCS#12. | 40bitový RC2 | 3 klíče 3DES s SHA1 (168 bitů) |
| Netscape Communicator (domácí a exportní verze) PKCS#12 export | 40bitový RC2 | 3 klíče 3DES s SHA1 (168 bitů) |
| Netscape Communicator (exportní verze) PKCS#12 import. | Pouze 40bitová šifra. | Všechno. |
| Netscape Communicator (domácí nebo fortifikovaná verze) import PKCS#12. | Všechno. | Všechno. |
| OpenSSL kód PKCS#12. | Všechno. | Všechno. |
Ve výchozím nastavení je nejsilnější šifrování podporováno všemi implementacemi aplikací pomocí PKCS#12: 3DES pro soukromé klíče a RC2-40 pro certifikáty. Další možnosti vám také umožňují šifrovat certifikát pomocí 3DES .
Je třeba poznamenat, že zatímco více verzí Netscape bude importovat soubory pomocí různých algoritmů, MSIE zřejmě podporuje pouze RC2 a 3DES .
Existuje několik mechanismů, které umožňují transformaci hesla uživatele na šifrovací klíč. Specifikace PKCS#5 je omezena na iterace MD2 a MD5 pro použití s klíči DES .
K vytvoření nebo převodu certifikátu potřebujete software OpenSSL . Funkce SSL v3 je definována takto:
klíč = MD5(heslo + SHA1(“A” + heslo + sůl)) + MD5(heslo + SHA1(“BB” + heslo + sůl)) + MD5(heslo + SHA1(“CCC” + heslo + sůl)) + ...trpí tím, že vstup použitý pro krok SHA-1 se liší pouze o několik bitů vstupu použitého v předchozím kroku a že vyžaduje použití dvou různých a pevných funkcí pro převod hesla na klíč. Navíc takto definovaná funkce neumožňuje opakovatelné zpracování nezbytné k zabránění opakování slovníku .
Funkce TLS rozšiřuje funkci SSL v3 a je definována takto:
klíč = HMAC(heslo, A(1) + sůl) + HMAC(heslo, A(2) + sůl) + ...kde A(0) = sůl je libovolné číslo, A(1) = HMAC ( heslo , A(0)), …
(ve skutečnosti: klíč je XOR aplikovaný přes HMAC-MD5 a HMAC-SHA1 , opět jsou vyžadovány dva různé pevné algoritmy). Další nevýhodou použití HMAC je, že velikost hesla je omezena na 64 znaků ASCII , nebo 32 nebo dokonce 16 pro širší znakovou sadu, kvůli požadavku na snížení délky klíčů jejich hashováním. Stejně jako u funkce SSL v3 neexistuje žádné ustanovení pro iteraci funkce, která by zabránila iteraci přes slovník .
Funkce odvození klíče X.9-42 je definována konkrétně v termínech SHA-1 :
klíč = SHA1(heslo + 1) + SHA1(heslo + 2) + ...Toto je pravděpodobně nejhorší funkce odvození klíče ze všech, která používá pevnou hashovací funkci , mění pouze jeden vstupní bit pro každý blok klíče, zavádí malé množství změněných dat po nastavení hesla, nikoli před ním a nelze jej opakovat.
Tyto předpoklady předkládají následující požadavky na zpracování uživatelského hesla:
Dalším užitečným cílem návrhu je učinit výstup závislým na šifrovacím algoritmu; klíč je generován tak, aby znemožnil útoky na obnovu klíče . Pokud je stejný klíč použit pro několik algoritmů, pak útočník, který může získat klíč pro jeden algoritmus, může tento útok použít při používání jiných algoritmů (například získání klíče DES vám umožní získat přibližně polovinu klíče IDEA ). Závislost výsledku kroku zpracování klíče na šifrovacím algoritmu, režimu a konfiguraci znamená, že klíč odvozený ze stejného hesla s použitím jiného režimu nebo konfiguračního algoritmu nebude snadné získat.
Tyto požadavky navrhují následující základní design:
klíč[] = { 0 }; stav = hash( algoritmus, režim, parametry, sůl, heslo ); pro počet = 1 do iterací pro délku = 1 až keyLength stav = hash(stav); klíč[ délka ] ^= hash( stav, heslo );Vnitřní stav závisí na všech vstupních parametrech (šifrovací algoritmus, režim, parametry, salt a samozřejmě heslo). V každém kroku zpracování pak stavové proměnné fungují jako generátor pseudonáhodných čísel , který zajišťuje, že vstupní parametry hašovací funkce použité při generování klíče se změní o počet bitů rovný výstupu hašovací funkce na každý krok a zajišťuje, že proces získávání klíče uživatelem je lineární, tj. jakákoli forma paralelizace nebo předvýpočtů není možná. Nakonec pomocí XORingu výstup úspěšného kroku zpracování a klíč v každé iteraci přispívá k výslednému klíči.
Vstupní parametry pro hashovací funkci používanou ke generování stavových proměnných:
StateHashData ::= SEQUENCE { encryptionAlgorithm AlgorithmIdentifier, sůl OCTET STRING VELIKOST (8) VOLITELNÉ, heslo UTF8String }Pole typu StateHashData mají následující význam:
encryptionAlgorithm — šifrovací algoritmus, režim a další parametry potřebné pro vygenerování klíče. Implementace musí podporovat 3DES-CBC .
salt je 64bitové náhodné číslo. Tuto hodnotu lze zanedbat, pokud je nutné získat klíč, který je pro dané heslo konstantní.
heslo je heslo uživatele reprezentované řetězcem UTF8 .
Vstupní parametry hashovací funkce použité k získání klíče:
KeyHashData ::= SEQUENCE { stav OCTET STRING, heslo UTF8String }stav je výstupem hašovací funkce založené na generátoru náhodných čísel .
heslo je heslo uživatele reprezentované řetězcem UTF8 .
Když je použit typ EncryptedData , pak je obsah contentEncryptionAlgorithm identifikován takto:
id-passwordBasedEncryption IDENTIFIKÁTOR OBJEKTU ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 43}
Relevantní možnosti:
PBEParameters ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, encryptionAlgorithm AlgorithmIdentifier, sůl OCTET STRING VELIKOST (8), iterationCount INTEGER(200...MAX_ITERATION) }Pole typu PBEParameters mají následující význam:
hashAlgorithm – hashovací algoritmus používaný ke zpracování hesla. Implementace musí podporovat SHA-1 a nejlépe MD5 a RIPEMD-160 .
encryptionAlgorithm je algoritmus používaný ke generování klíče a šifrování dat. Má stejný význam jako v StateHashData .
slat - má stejný význam jako v StateHashData .
iterationCount – počet iterací hash, které se mají provést. Pro přiměřené zabezpečení se doporučuje použít asi 500 operací, které na typické pracovní stanici zaberou méně než sekundu.
To však neplatí ani pro objekty certifikátu. Důvodem je, že zajištění integrity souborů PKCS#12 je volitelné, jak je znázorněno zde:
PFX ::= SEQUENCE { verze INTEGER {v3(3)}(v3,...), authSafe ContentInfo, macData MacData VOLITELNÉ }Vzhledem k tomu, že tento ovládací prvek je volitelný, lze jej zakázat a poté lze obsah souboru změnit bez detekce nebo varování. K přidání objektů certifikátu tedy není vyžadováno řízení přístupu. V tomto případě jsou certifikáty použity v SSL PKI jako Trust Anchor , což umožňuje útočníkovi vložit Trust Anchor jejich CA do těchto souborů bez potřeby jakékoli autorizace.
Jakmile je útočníkova Trust Anchor vložena do napadeného systému, bude důvěřovat a rozpoznat jakýkoli certifikát vydaný útočníkovou CA.
Útokem může být útok typu man-in-the-middle , který zachytí soubory během přenosu a vloží nepřátelskou Trust Anchor . V tomto případě by útok mohl stejně dobře fungovat proti systémům, které nepoužívají soubory PKCS#12, jako je úložiště klíčů, ale tento útok má nevýhodu v tom, že jakmile je útok odhalen, může být detekován falešný certifikát.
Přípona souboru : ".p12" nebo ".pem". Tyto soubory lze vytvořit pomocí OpenSSL .
Na základě článku: Vytváření certifikátů PKCS12
Nastavení prostředíVytvořte adresář (např. cert) a přejděte do něj. Vytvořte v něm prázdný soubor certindex.txt Spusťte příkazy:
mkdir soukromý mkdir certifikáty echo '100001' > sériové klepněte na certindex.txtV tomto adresáři vytvořte konfigurační soubor openssl.conf s následujícím obsahem:
# # Konfigurační soubor OpenSSL. # # Vytvořte pracovní adresář. dir = . [ca] default_ca = CA_default [CA_default] serial = $dir/serial databáze = $dir/certindex.txt new_certs_dir = $dir/certs certifikát = $dir/cacert.pem private_key = $dir/private/cakey.pem default_days = 365 default_md=md5 zachovat = ne email_in_dn = ne nameopt = default_ca certopt=default_ca policy = policy_match [policy_match] countryName = shoda stateOrProvinceName = shoda OrganizationName = shoda OrganizationUnitName = volitelné commonName = dodáno emailAddress = volitelné [požadavek] default_bits = 1024 # Velikost klíčů default_keyfile = key.pem # název vygenerovaných klíčů default_md = md5 # algoritmus pro shrnutí zpráv string_mask = nombstr # povolené znaky rozlišovací_jméno = požadované_rozlišovací_jméno req_extensions = v3_req [req_distinguished_name] # Název proměnné Řetězec výzvy #--------------------------------- ---------------- ------- ---------- 0.organizationName = Název organizace (společnosti) OrganizationUnitName = Název organizační jednotky (oddělení, divize) emailAddress = EmailAddress emailAddress_max = 40 localityName = LocalityName (město, okres) stateOrProvinceName = Název státu nebo provincie (celé jméno) countryName = CountryName (dvoupísmenný kód) countryName_min = 2 countryName_max = 2 commonName = Common Name (název hostitele, IP nebo vaše jméno) commonName_max = 64 # Výchozí hodnoty pro výše uvedené pro konzistenci a méně psaní. # Název proměnné Hodnota #------------------------ ------------------------- ----- 0.organizationName_default = Společnost localityName_default = Moskva stateOrProvinceName_default = Moskva countryName_default = RU emailAddress_default = email@domain.ru commonName_default = společný text [v3_ca] basicConstraints = CA:TRUE subjectKeyIdentifier = hash AuthorityKeyIdentifier = ID klíče:vždy,vydavatel:vždy [v3_req] basicConstraints = CA:FALSE subjectKeyIdentifier = hash Generování certifikátu certifikačního úřadu openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.confAž budete vyzváni k zadání hesla, zadejte heslo o délce alespoň 4 znaků. Pro všechny ostatní dotazy můžete stisknout Enter .
Vytvoření uživatelského certifikátuNejprve nastavíme název pro soubory certifikátu uživatele. Protože jich může být mnoho, nastavení pomocí proměnné prostředí vám umožní velmi rychle opakovat tento krok pro každého uživatele.
name='user'Nyní pro každého uživatele vytvoříme certifikát PKCS12. Spusťte jeden příkaz najednou:
openssl req -new -nodes -out $name-req.pem -keyout private/$name-key.pem -days 365 -config ./openssl.conf openssl ca -out $name-cert.pem -days 365 -config ./openssl.conf -infiles $name-req.pem openssl pkcs12 -export -in $name-cert.pem -inkey private/$name-key.pem -certfile cacert.pem -name "description" -out $name-cert.p12Až budete vyzváni k zadání hesla, použijte heslo, které bylo nastaveno při vytváření certifikátu CA. Pro všechny ostatní dotazy můžete stisknout Enter .
Hotový soubor: user-cert.p12
Tento soubor lze importovat do Firefoxu nebo Thunderbirdu a poté použít v OpenOffice.org.
Řekněme, že potřebujeme vytvořit soubor cert.p12 . Řekněme, že máme soubory soukromého klíče prkey.pem a soubor certifikátu cert.pem . Můžete to udělat pomocí příkazu openssl pkcs12 :
openssl pkcs12 -export -in cert.pem -inkey prkey.pem -name "Můj certifikát" -out cert.p12kde -name je klíč, který určuje ID vašeho certifikátu. V našem příkladu se tedy v uživatelském programu zobrazí řetězec "Můj certifikát" . Při pokusu o přístup k certifikátu budete nejprve požádáni o zadání hesla pro aktuální soukromý klíč a poté o heslo pro soubor PKCS#12 (*.p12). Navíc bude heslo ze souboru PKCS #12 požadováno dvakrát.
Po určité době se certifikát stává neplatným. Pokud se jedná o potvrzení zaměstnance, tak např. po jeho propuštění je třeba potvrzení považovat za neplatné. Pokud se soukromý klíč certifikátu z nějakého důvodu stal veřejným, musí být také přidán do seznamu neplatných certifikátů (CRL). Ke správě CRL můžete použít příkaz openssl ca.
Vytváření seznamů CRL:
openssl ca -gencrl -out crl.pemPřidání nepotřebných certifikátů se provádí pomocí příkazu:
openssl ca -revoke bad_cert.pemPo každé aplikaci revokace je nutné aktualizovat CRL příkazem
openssl ca -gencrlVíce informací lze nalézt v manuálu pomocí příkazu man pkcs12 v linuxovém terminálu nebo odkazu pkcs12(1) .
Tato část je založena na LirJSSE, rozšíření Secure Sockets GOST Algorithm Support Extension pro Javu . Další informace o implementaci PKCS#12 v knihovně JSSE naleznete ve zdroji.
Poskytovatel SunJSSE poskytuje kompletní implementaci formátu PKCS#12 java.security.KeyStore pro čtení a zápis souborů pkcs12. Tento formát podporují i další nástroje a aplikace pro import a export klíčů a certifikátů, jako je Netscape / Mozilla , Microsoft Internet Explorer a OpenSSL . Tyto implementace mohou například exportovat klientské certifikáty a klíče do souboru s příponou „.p12“.
S poskytovatelem LirJSSE můžete získat klíče PKCS#12 prostřednictvím rozhraní API KeyStore s typem úložiště "pkcs12". Kromě toho můžete zobrazit seznam nainstalovaných klíčů a odpovídajících certifikátů pomocí příkazu keytool s volbou -storetype nastavenou na pkcs12.
Pro každý případ je třeba mít na paměti, že v Java 6 JDK jsou stejné třídy podpory úložiště PKCS#12 obsaženy nejen uvnitř JSSE , ale také samostatně v balíčku sun.security.pkcs12 .
Implementace úložiště PKCS#12 v LirJSSE navíc podporuje algoritmy GOST. Následuje popis funkcí této implementace.
Když je úložiště načteno, je zkontrolována jeho integrita digestu a poté jsou všechny řetězce certifikátů dešifrovány. Tajný klíč je dešifrován pouze na žádost s konkrétním aliasem, ale zůstává v zašifrovaném stavu ve veřejném úložišti. Šifrování všech řetězců certifikátů a výpočet přehledu úložiště se provádějí pouze při uložení úložiště do souboru.
Řetězce certifikátů jsou spojeny se soukromými klíči v úložišti pomocí místních identifikátorů. Lokální identifikátor je pole bajtů UTF-8 vytvořené přidáním nového klíče z řetězce "Time" následovaného textovou reprezentací data a času přidání prvku. Když je přidán nový klíč, vždy je také specifikován odpovídající řetězec certifikátů a heslo.
Nový tajný klíč lze odeslat k přidání do trezoru v jasné formě nebo již zašifrovaný. V druhém případě není heslo klíče specifikováno.
Úschovna nemůže obsahovat současně klíče GOST i jiné než GOST . Odpovídající typ vnitřního úložiště se nastaví buď při jeho načtení, nebo při přidání prvního klíče. Pokud je úložiště prázdné, pak jeho typ není v tomto smyslu definován.
Alias pro klíčový prvek je obecně volitelný. Pokud je v úložišti prvek bez aliasu, pak je mu alias přidělen násilně ve formě interního sériového čísla. Faktem je, že LirJSSE , stejně jako Sun JSSE , pracuje s úložnými prvky pouze pomocí aliasů.
Při vytváření prvků úložiště různými programy se může vnitřní struktura ukládání šifrovaných prvků mírně lišit. Z tohoto důvodu může být například stejný řetězec certifikátů zabalen do souboru úložiště pomocí LirSSL a LirJSSE do struktur různých velikostí. Norma to umožňuje a nemá to vliv na funkčnost úložiště.
Při práci s JSSE nezapomeňte, že hesla klíčových prvků se musí shodovat s heslem úložiště. Standard PKCS#12 obecně umožňuje více hesel ve stejném úložišti, ale SunJSSE a LirJSSE tuto funkci nepodporují.
Po dohodě s firmou Top Cross je heslo celého úložiště před použitím převedeno v programu LirJSSE do formátu UTF-16 (poslední dva bajty jsou nula). A jednotlivé prvky úložiště jsou chráněny stejným heslem, ale ve formátu UTF-8 .
LirJSSE - Secure Sockets Extension with GOST Algorithms for Java poskytuje srovnávací popis vnitřní struktury souborů úložiště PKCS#12 ve formátu ASN.1 pro varianty RSA a GOST .