| PKCS#12 | |
|---|---|
| Kiterjesztés | .p12[1] vagy [1].pfx |
| MIME típusú | application/x-pkcs12 [1] |
| Fejlesztő | RSA biztonság [d] |
| közzétett | 1996 |
| Legutolsó kiadás |
PKCS #12 v1.0 (1999. június 24. 1. műszaki javítás / 2000. február 25. ) |
| Formátum típusa | Archívum |
| Tartalmaz | X.509 nyilvános kulcsú tanúsítványok , X.509 privát kulcsok , X.509 CRL - ek , általános adatok |
| Kibontva innen | Microsoft PFX fájlformátum |
A kriptográfiában a PKCS#12 az RSA Laboratories által közzétett nyilvános kulcsú titkosítási szabványok (PKCS) egyike . Meghatározza a privát kulcs ( en:Private key ) tárolására és/vagy szállítására használt fájlformátumot , a bizalmi láncot a felhasználó tanúsítványától a CA gyökértanúsítványáig , valamint a tanúsítvány-visszavonási listát (CRL). A fájlt kétféleképpen védjük: biztonságosan, megbízható kulcspár használatával (digitális aláírásra és titkosításra alkalmas nyilvános/privát kulcsok) vagy kevésbé biztonságosan, jelszó alapú szimmetrikus kulcs használatával. A második olyan esetekre alkalmas, amikor a megbízható nyilvános/privát kulcspárok használata nem érhető el. A PKCS#12 formátum egy kulcspár (magánkulcs és tanúsítvány) tárolására tervezett formátum, amelyet számos böngésző és levelezőügynök felismer és használ. A PKCS#12 fájlok a tanúsítványt és a privát kulcsot is tárolják (természetesen titkosított formában). Egy példa a PKCS#12 fájlszervezésre a jobb oldali ábrán látható.
Ez a szabvány leírja a személyazonosító adatok átvitelének szintaxisát, beleértve a privát kulcsokat, tanúsítványokat, különféle titkokat stb. Ez a szabvány támogatja a közvetlen adatátvitelt a küldő platform és a fogadó platform között. A szabvány mind magas szintű védelemmel (digitális aláíráshoz és titkosításhoz használt nyilvános/privát kulcspár használatával), mind alacsonyabb szintű védelemmel (jelszavas engedélyezéssel) támogatja az adatok átvitelét abban az esetben, ha nyilvános /privát kulcs kulcs nem érhető el.
A szabványt hardveresen és szoftveresen is megvalósítják. Hardveres megvalósításra példa a biztonságos tokenek, például a Smart Card és a PC Card .
Ez a szabvány a PKCS8 szabvány kiterjesztésének tekinthető . További azonosító információkat tartalmaznak, beleértve a privát kulcsokat is. Magas biztonsági módot vezetett be a nyilvános kulcs elrejtésével.
Néhány évvel ezelőtt a titkosítási rendszereket csak kivételes esetekben alkalmazták: kormányzati szervezetekben, hírszerző ügynökségekben és más, az adatbiztonság szempontjából kritikus rendszerekben. Jelenleg azonban a számítógépes hálózatok és az internet rohamos fejlődése egyre több embert késztet a biztonság gondolatára. Manapság mindenkit aggaszt a hálózaton keresztül továbbított adatok biztonsága. Ennek eredményeként számos különböző tanúsítvány és titkosítási módszer jelent meg . Ez a cikk a PKCS#12 kulcstárolási formátumot és a tanúsítvány privát kulcsainak biztonságos tárolásával kapcsolatos néhány problémát tárgyalja.
Az évek során számos tárolási formátumot hoztak létre az eredeti PKCS5 és PKCS8 formátumok mellett, amelyek a DES és MD5 formátumokra korlátozódtak . Ez az inkompatibilis és gyakran nem biztonságos privát kulcs tárolási formátumok elterjedéséhez vezetett. Ez a rendkívül összetett PKCS12 formátumban csúcsosodott ki, az inkompatibilis objektumazonosítók, algoritmusok, adattartalom és feldolgozási követelmények keverékével. Ennek a zűrzavarnak az eredményeként a megvalósítás nem volt biztonságos és nem kompatibilis a régebbi verziókkal. Mivel a követelmények nem nyújtottak elegendő információt a kompatibilis verziók megvalósításához. Egy másik probléma ezzel a formátummal az adatfelfúvódás volt, ami használhatatlanná tette a korlátozott memóriájú eszközökben, például az intelligens kártyákban való használatát .
Ezek a változtatások rávilágítottak a magánkulcs-tároló formátumok egyszerűsítésének, biztonságának és interoperabilitásának szükségességére. A fejlesztők feladatai ennél a formátumnál a következők voltak:
A PKCS#12 a Microsoft "PFX" utódja . A "PKCS#12 fájl" és a "PFX fájl" kifejezéseket néha felcserélhetően használják.
A PFX-et erősen kritizálták amiatt, hogy az egyik legbonyolultabb kriptográfiai protokoll, mégis ez az egyetlen szabványos módja a privát kulcsok és tanúsítványok egyetlen titkosított fájlban való tárolásának.
A Netscape a PFX formátumot használta a PKCS#12 helyett a 4.03-as és korábbi verziókban, mivel a PKCS#12 formátum egyszerűen nem létezett. A visszafelé kompatibilitás szükségessége miatt a Netscape 4.04 és újabb verziói, valamint az MSIE összes verziója csak a PFX importálást támogatta. Az alábbi táblázat összefoglalja a fentieket.
| Szoftver | PKCS#12 importálás | PKCS#12 exportálás | PFX import | PFX export |
|---|---|---|---|---|
| Netscape 4.03 és korábbi | Igen. | Igen. | Igen. | Igen. |
| Netscape 4.04 és újabb | Igen. | Igen. | Igen. | Igen. |
| MSIE 4.0 és újabb | Igen. | Igen. | Igen. | Igen. |
SD
Az adatvédelmi és méltányossági módok bármilyen kombinációja megengedett ebben a szabványban. Természetesen a jó biztonsági politika bizonyos gyakorlatok elkerülését jelenti. Például ostobaság lenne egy privát kulcsot fizikai védelem nélkül továbbítani.
Mindkét módban (bizalmasság és őszinteség) jobb nyilvános kulcsot használni, mint jelszót. Azonban nem mindig lehetséges a mód használata a nyilvános kulcs használatával. Például, ha a küldés időpontjában nem tudunk elegendő információt a címzett platformjáról. Ebben az esetben a nyilvános kulcsot használó mód csak zavarja.
A privát/nyilvános kulcspár két paraméterkészletből áll. A további azonosító információkat, például felhasználóneveket és e-mail címeket tartalmazó nyilvános beállításokat a rendszer titkosítatlanul tárolja. A privát opciókat többnyire valamilyen védelmi mechanizmussal, például titkosítással tárolják.
A konténer formátumát a PKCS#7 és az S/MIME által megvalósított formátum alapján határozták meg . A következő objektumazonosító azonosítja a titkos kulcs tartalmának biztonságos tárolási típusát.
id-securedPrivateKey OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 42 }A privát kulcs tartalmának biztonságos tárolási típusának ASN.1 SecuredPrivateKey típusúnak kell lennie:
SecuredPrivateKey ::= SEQUENCE { verzió Verzió, publicKey, privateKey ContentInfo }A SecuredPrivateKey típusú mezők jelentése a következő:
verzió – szintaxis verziószám, 0-nak kell lennie.
publicKey – A kulcs nyilvános összetevője és a kulcs tulajdonosára vonatkozó további azonosító információk.
A privateKey egy biztonságos privát kulcs, amely a tartalomtípus-azonosítóból és magából a tartalomból áll.
A nyilvános kulcs komponensei titkosítatlan formában vannak tárolva. Ez azért történik, mert nincs elég jó ok az adatok titkosítására. Mivel ezeknek az adatoknak bármilyen adatfolyam -rejtjellel titkosítása jelentős mennyiségű ismert rejtjelezett szövegnek teszi ki a támadót, és lehetővé kell tenni, hogy a felhasználó jelszókérés nélkül hozzáférjen nyilvános kulcsához. A nyilvános kulcs információit a PublicKeyInfo típus képviseli :
PublicKeyInfo ::= CHOICE { publicKeyInfo SubjectPublicKeyInfo, -- Nyers nyilvános kulcs információ certRequest [ 0 ] EXPLICIT PKCS10CertRequest, -- PKCS #10 cert.req. tanúsítvány [ 1 ] EXPLICIT tanúsítvány, -- X.509 tanúsítvány certChain [ 2 ] EXPLICIT PKCS7CertChain — PKCS #7 cert.chain }A legegyszerűbb formában a nyilvános kulcs SubjectPublicKeyInfoként van tárolva . A hitelesítési kérelem generálása után a „nyers” nyilvános kulcs információi szükség szerint cserélhetők, és amikor a kulcsot hitelesítették, a tanúsítvány vagy a teljes tanúsítványrejtjel tárolható.
A privát kulcs komponensei titkosított vagy titkosítatlan formában is tárolhatók. A titkosított űrlap használata javasolt mindaddig, amíg az adatok más módon nem védettek. Ha az adatokat titkosítatlan formában tárolják, akkor a rendszer az Adattartalom típust használja . Ha az adatokat titkosított formában tárolják, akkor az EncryptedData típust használja a contentEncryptionAlgorithm - a titkosítási algoritmus, a mód és a kulcs generálásakor használt további paraméterek. A PublicKeyInfo-ban megadott nyilvános kulcsmezőkkel megegyező privát kulcs mezők tartalma vagy titkosított tartalma (a megfelelő nyilvános kulcs mezők nélkül).
Például az RSA esetében :
RSAPrivateKey ::= SEQUENCE { privateExponent INTEGER, -- Privát kitevő d prím1 INTEGER, -- n p prímtényezője prím2 INTEGER, -- n q prímtényezője kitevő1 INTEGER, -- d mod (p-1) kitevő2 INTEGER, -- d mod (q-1) együttható INTEGER—CRT együttható (q^-1) mod p }DSA és ElGamal rendszer esetén :
DSAPrivateKey ::= SEQUENCE { x INTEGER – Privát véletlenszerű egész szám }Az okok, amiért csak a privát kulcsmezőket tárolják, a következők: először is a redundancia elkerülése érdekében (minden mást már tartalmaz a PublicKeyInfo); másodszor azért, hogy kiküszöböljük a kulcsfolyam jelentős összegének triviális helyreállításának lehetőségét a kulcs elején lévő ismert nyilvános mezők használatával.
A PKCS#12 a következő titkosítási algoritmusokat támogatja:
Ezenkívül a PKCS#5 v1.5 mód is támogatott . Ez lehetővé teszi a következő algoritmusok használatát:
A PKCS#5 v2.0 használata lehetővé teszi egy tetszőleges titkosítási algoritmus használatát.
Az OpenSSL képes kezelni a PKCS#5 v1.5 -ös és v2.0 -s verzióját a PKCS#12 fájlokban, de más megvalósítások nem támogatottak.
Az alábbi táblázat összefoglalja a különböző titkosítások támogatását:
| Szoftver és mód. | Tanúsítvány titkosítás | Privát kulcsos titkosítás |
|---|---|---|
| MSIE4 (hazai és export verziók) PKCS#12 export. | 40 bites RC2 . | 40 bites RC2 . |
| MSIE4, 5 (hazai és export verziók) PKCS#12 import. | 40 bites RC2 , 3 kulcsos 3DES . | 40 bites RC2 , 3 kulcsos 3DES . |
| MSIE5 PKCS#12 exportálás. | 40 bites RC2 | 3 kulcsos 3DES SHA1 -gyel (168 bit) |
| Netscape Communicator (hazai és export verziók) PKCS#12 export | 40 bites RC2 | 3 kulcsos 3DES SHA1 -gyel (168 bit) |
| Netscape Communicator (export verzió) PKCS#12 import. | Csak 40 bites titkosítás. | Összes. |
| Netscape Communicator (hazai vagy erősített verzió) PKCS#12 import. | Összes. | Összes. |
| OpenSSL PKCS#12 kód. | Összes. | Összes. |
Alapértelmezés szerint a legerősebb titkosítást támogatja az összes olyan alkalmazás-megvalósítás, amely a PKCS#12: 3DES -t használja a privát kulcsokhoz és az RC2-40 -et a tanúsítványokhoz. Ezenkívül további lehetőségek lehetővé teszik a tanúsítvány titkosítását 3DES használatával .
Meg kell jegyezni, hogy míg a Netscape több verziója különböző algoritmusokkal importálja a fájlokat, addig az MSIE csak úgy tűnik, hogy támogatja az RC2 -t és a 3DES -t .
Számos mechanizmus létezik, amelyek lehetővé teszik a felhasználó jelszavának titkosítási kulccsá alakítását. A PKCS#5 specifikáció az MD2 és MD5 iterációkra korlátozódik a DES kulcsokkal való használatra .
Tanúsítvány létrehozásához vagy átalakításához OpenSSL szoftverre van szükség . Az SSL v3 funkció meghatározása a következő:
kulcs = MD5 (jelszó + SHA1 ("A" + jelszó + só) + MD5 (jelszó + SHA1 ("BB" + jelszó + só)) + MD5 (jelszó + SHA1 ("CCC" + jelszó + só)) + ...szenved attól, hogy az SHA-1 lépéshez használt bemenet csak néhány bittel tér el az előző lépésben használt bemenettől, és két különböző és rögzített függvény használata szükséges ahhoz, hogy a jelszót kulccsá alakítsák. Ezenkívül az így definiált függvény nem teszi lehetővé a szótáriteráció megakadályozásához szükséges iterálható feldolgozást .
A TLS függvény kiterjeszti az SSL v3 függvényt, és a következőképpen definiálható:
kulcs = HMAC(jelszó, A(1) + só) + HMAC(jelszó, A(2) + só) + ...ahol A(0) = só egy tetszőleges szám, A(1) = HMAC ( jelszó , A(0)), …
(tényként: a kulcs a HMAC-MD5 és HMAC-SHA1 keresztül alkalmazott XOR , ismét két különböző rögzített algoritmus szükséges). A HMAC használatának másik hátránya, hogy a jelszó mérete 64 ASCII karakterre van korlátozva, szélesebb karakterkészlet esetén pedig 32 vagy akár 16 karakterre korlátozódik, mivel a kulcsok hosszát kivonatolva kell csökkenteni. Csakúgy, mint az SSL v3 függvénynél, a szótáron keresztüli iteráció megakadályozása érdekében a függvény iterációjára nincs lehetőség .
Az X.9-42 kulcs levezetési függvény kifejezetten az SHA-1 szempontjából van definiálva :
kulcs = SHA1 (jelszó + 1) + SHA1 (jelszó + 2) + ...Valószínűleg ez a legrosszabb kulcslevezetési függvény az összes közül, fix hash függvényt használva , csak egyetlen bemeneti bitet változtat meg a kulcs minden egyes blokkjához, és a jelszó beállítása után, nem előtte, és nem iterálható, csak egy kis mennyiségű módosított adatot vezet be.
Ezek a feltételezések a következő követelményeket támasztják a felhasználói jelszavak feldolgozásával kapcsolatban:
Egy másik hasznos tervezési cél a kimenet függővé tétele a titkosítási algoritmustól; a kulcsot úgy állítják elő, hogy lehetetlenné tegye a kulcs-helyreállítási támadásokat . Ha ugyanazt a kulcsot több algoritmushoz is használják, akkor egy támadó, aki meg tudja szerezni egy algoritmus kulcsát, használhatja ezt a támadást, miközben más algoritmusokat használ (például egy DES kulcs megszerzése lehetővé teszi az IDEA kulcs körülbelül felét ). A kulcsfeldolgozási lépés eredményét a titkosítási algoritmustól, módtól és konfigurációtól függővé tétele azt jelenti, hogy nem lesz könnyű megszerezni egy másik módot vagy konfigurációs algoritmust használó, ugyanabból a jelszóból származó kulcsot.
Ezek a követelmények a következő alapvető kialakítást javasolják:
kulcs[] = {0}; állapot = hash( algoritmus, mód, paraméterek, só, jelszó ); for count = 1 az iterációkhoz hossza = 1 - keyLength állapot = hash(állapot); kulcs[hossz] ^= hash( állapot, jelszó );A belső állapot minden bemeneti paramétertől függ (titkosítási algoritmus, mód, paraméterek, só és természetesen a jelszó). Ezután minden feldolgozási lépésben az állapotváltozók pszeudo-véletlen számgenerátorként működnek , amely biztosítja, hogy a kulcs generálásához használt hash függvény bemeneti paraméterei a hash függvény kimenetével megegyező számú bittel megváltozzanak minden lépésben, és biztosítja, hogy a kulcs felhasználó általi megszerzésének folyamata lineáris legyen, azaz a párhuzamosítás vagy az előszámítás semmilyen formája nem lehetséges. Végső soron egy sikeres feldolgozási lépés kimenetének XOR-elésével, és az egyes iterációknál található kulcs hozzájárul a kapott kulcshoz.
Az állapotváltozók generálásához használt hash függvény bemeneti paraméterei:
StateHashData ::= SEQUENCE { encryptionAlgorithm AlgorithmIdentifier, só OCTET STRING MÉRETE (8) OPCIONÁLIS, jelszó UTF8String }A StateHashData típusú mezők jelentése a következő:
encryptionAlgorithm — titkosítási algoritmus, mód és a kulcs generálásához szükséges további paraméterek. A megvalósításnak támogatnia kell a 3DES-CBC- t .
A só egy 64 bites véletlenszám. Ez az érték figyelmen kívül hagyható, ha egy adott jelszóhoz állandó kulcsot kell beszerezni.
A jelszó a felhasználó jelszava, amelyet egy UTF8 karakterlánc képvisel .
A kulcs megszerzéséhez használt hash függvény bemeneti paraméterei:
KeyHashData ::= SEQUENCE { állapot OCTET STRING, jelszó UTF8String }Az állapot egy véletlenszám-generátoron alapuló hash függvény kimenete .
A jelszó a felhasználó jelszava, amelyet egy UTF8 karakterlánc képvisel .
Az EncryptedData típus használata esetén a contentEncryptionAlgorithm tartalma a következőképpen kerül azonosításra:
id-passwordBasedEncryption OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 43}
Lényeges lehetőségek:
PBEParameters ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, encryptionAlgorithm AlgorithmIdentifier, só OCTET STRING MÉRET (8), iterációszám INTEGER(200...MAX_ITERATION) }A PBEParameters típusú mezők jelentése a következő:
hashAlgorithm – a jelszó feldolgozására használt hash algoritmus. A megvalósításnak támogatnia kell az SHA-1- et és lehetőleg az MD5 -öt és a RIPEMD-160-at .
Az encryptionAlgoritm a kulcs generálására és az adatok titkosítására használt algoritmus. Ugyanaz a jelentése, mint a StateHashData -ban .
slat - ugyanaz a jelentése, mint a StateHashData -ban .
iterationCount – a végrehajtandó hash iterációk száma. Az ésszerű biztonság érdekében körülbelül 500 művelet elvégzése javasolt, ami egy tipikus munkaállomáson kevesebb mint egy másodpercet vesz igénybe.
Ez azonban nem igaz a tanúsítványobjektumokra sem. Ennek az az oka, hogy a PKCS#12 fájlok integritásának biztosítása nem kötelező, amint az itt látható:
PFX ::= SEQUENCE { version INTEGER {v3(3)}(v3,...), authSafe ContentInfo, macData MacData OPCIONÁLIS }Mivel ez a vezérlő nem kötelező, letiltható, majd a fájl tartalma észlelés vagy figyelmeztetés nélkül módosítható. Ezért nincs szükség hozzáférés-vezérlésre a tanúsítványobjektumok hozzáadásához. Ebben az esetben a tanúsítványok az SSL PKI -ben megbízhatósági horgonyként használatosak, és ez lehetővé teszi a támadó számára, hogy engedély nélkül illessze be CA Trust Anchor -jét ezekbe a fájlokba.
Miután a támadó megbízhatósági horgonyját behelyezték a megtámadott rendszerbe, az megbízik és felismeri a támadó hitelesítésszolgáltatója által kiadott tanúsítványokat.
A támadás lehet egy ember a közepén támadás , amely továbbítás közben elfogja a fájlokat, és beilleszt egy ellenséges Trust Anchor -t . Ebben az esetben a támadás ugyanúgy működhet olyan rendszerek ellen is, amelyek nem használnak PKCS#12 fájlokat, például a kulcstárolót, de ennek a támadásnak az a hátránya, hogy a támadás felfedezése után egy hamis tanúsítvány észlelhető.
Fájlkiterjesztés : ".p12" vagy ".pem". Ezek a fájlok OpenSSL -lel hozhatók létre .
A cikk alapján: PKCS12 tanúsítványok létrehozása
A környezet beállításaHozzon létre egy könyvtárat (pl. cert) és változtassa meg. Hozzon létre benne egy üres certindex.txt fájlt Futtassa a parancsokat:
mkdir privát mkdir certs echo '100001' > soros érintse meg a certindex.txt fájltEbben a könyvtárban hozza létre az openssl.conf konfigurációs fájlt a következő tartalommal:
# # OpenSSL konfigurációs fájl. # # Munkakönyvtár létrehozása. dir = . [ca] default_ca = CA_default [CA_default] soros = $dir/serial adatbázis = $dir/certindex.txt new_certs_dir = $könyvtár/tanúsítványok tanúsítvány = $dir/cacert.pem private_key = $dir/private/cakey.pem alapértelmezett_napok = 365 default_md=md5 megőrizni = nem email_in_dn = nem nameopt = alapértelmezett_ca certopt=default_ca policy = policy_match [policy_match] countryName = egyezés stateOrProvinceName = egyezés szervezetnév = egyezés OrganizationalUnitName = opcionális commonName = megadva emailAddress = opcionális [req] default_bits = 1024 # A kulcsok mérete default_keyfile = key.pem # generált kulcsok neve default_md = md5 # üzenetkivonat algoritmus string_mask = nombstr # engedélyezett karakter megkülönböztetett_név = kért_megkülönböztetett_név req_extensions = v3_req [req_distinguished_name] # Változónév Prompt string #--------------------------------- ----------------- ------- ----------- 0.organizationName = Szervezet neve (vállalat) OrganizationalUnitName = Szervezeti egység neve (részleg, részleg) emailAddress = EmailAddress emailAddress_max = 40 localityName = LocalityName (város, kerület) stateOrProvinceName = Állam vagy tartomány neve (teljes név) countryName = OrszágName (2 betűs kód) országName_min = 2 országName_max = 2 commonName = Közös név (gazdanév, IP vagy az Ön neve) commonName_max = 64 # A fentiek alapértelmezett értékei a következetesség és a kevesebb gépelés érdekében. # Változónév Érték #------------------------ -------------------------- ----- 0.organizationName_default = Vállalat localityName_default = Moszkva stateOrProvinceName_default = Moszkva countryName_default = RU emailAddress_default = [email protected] commonName_default = gyakori szöveg [v3_ca] basicConstraints = CA:TRUE tárgyKeyIdentifier = hash AuthorityKeyIdentifier = kulcsazonosító:mindig,kibocsátó:mindig [v3_req] basicConstraints = CA:FALSE tárgyKeyIdentifier = hash A hitelesítő hatóság tanúsítványának generálása openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.confAmikor a rendszer jelszót kér, adjon meg egy legalább 4 karakterből álló jelszót. Minden más lekérdezéshez nyomja meg az Enter billentyűt .
Felhasználói tanúsítvány létrehozásaElőször adjunk meg egy nevet a felhasználó tanúsítványfájljainak. Mivel sok lehet, a környezeti változón keresztül történő beállítás lehetővé teszi, hogy ezt a lépést nagyon gyorsan megismételje minden felhasználó számára.
név='felhasználó'Most minden felhasználó számára létrehozunk egy PKCS12 tanúsítványt. Futtasson egy parancsot egyszerre:
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 "leírás" -out $name-cert.p12Amikor a rendszer jelszót kér, használja azt a jelszót, amelyet a CA-tanúsítvány létrehozásakor állított be. Minden más lekérdezéshez nyomja meg az Enter billentyűt .
Kész fájl: user-cert.p12
Ez a fájl importálható Firefoxba vagy Thunderbirdbe, majd használható az OpenOffice.org webhelyen.
Tegyük fel, hogy létre kell hoznunk egy cert.p12 fájlt . Tegyük fel, hogy van prkey.pem privát kulcs fájlja és cert.pem tanúsítványfájlja . Ezt az openssl pkcs12 paranccsal teheti meg :
openssl pkcs12 -export -in cert.pem -inkey prkey.pem -name "Saját tanúsítványom" -out cert.p12ahol a -name a tanúsítvány azonosítóját meghatározó kulcs. Így példánkban a "Saját tanúsítványom" karakterlánc jelenik meg a felhasználói programban. Amikor megpróbál hozzáférni a tanúsítványhoz, először meg kell adnia az aktuális privát kulcs jelszavát, majd a PKCS#12 fájl (*.p12) jelszavát. Ezenkívül a PKCS # 12 fájlból származó jelszót kétszer kell kérni.
Egy bizonyos idő elteltével a tanúsítvány érvénytelenné válik. Ha ez egy alkalmazotti igazolás, akkor például az elbocsátása után az igazolást érvénytelennek kell tekinteni. Ha a tanúsítvány privát kulcsa valamilyen okból nyilvánossá vált, akkor azt is hozzá kell adni az érvénytelen tanúsítványlistához (CRL). Az openssl ca paranccsal kezelheti a CRL-t .
CRL-ek létrehozása:
openssl ca -gencrl -out crl.pemA szükségtelen tanúsítványok hozzáadása a következő paranccsal történik:
openssl ca -revoke bad_cert.pemA visszavonás minden egyes alkalmazása után frissíteni kell a CRL-t a paranccsal
openssl ca -gencrlTovábbi információk a kézikönyvben találhatók a man pkcs12 parancs használatával a Linux terminálban, vagy a pkcs12(1) hivatkozással .
Ez a szakasz a LirJSSE-n alapul, amely egy Secure Sockets GOST Algorithm Support Extension for Java kiterjesztés . A PKCS#12 JSSE -könyvtárban való megvalósításával kapcsolatos további információkért tekintse meg a forrást.
A SunJSSE szolgáltató a PKCS#12 formátumú java.security.KeyStore teljes megvalósítását biztosítja a pkcs12 fájlok olvasásához és írásához. Ezt a formátumot a kulcsok és tanúsítványok importálására és exportálására szolgáló egyéb eszközök és alkalmazások is támogatják, például a Netscape / Mozilla , a Microsoft Internet Explorer és az OpenSSL . Ezek a megvalósítások például „.p12” kiterjesztésű fájlba exportálhatják az ügyféltanúsítványokat és -kulcsokat.
A LirJSSE szolgáltatóval PKCS#12 kulcsokat szerezhet be a KeyStore API-n keresztül a „pkcs12” tárolótípussal. Ezenkívül megtekintheti a telepített kulcsok és a megfelelő tanúsítványok listáját a keytool paranccsal , a -storetype paraméter pkcs12 értékre állítva.
Minden esetre ne feledje, hogy a Java 6 JDK -ban ugyanazok a PKCS#12 tárolótámogatási osztályok nemcsak a JSSE -ben, hanem külön-külön is megtalálhatók a sun.security.pkcs12 csomagban .
A LirJSSE PKCS#12 tárolási megvalósítása emellett támogatja a GOST algoritmusokat. Az alábbiakban ennek a megvalósításnak a jellemzőit ismertetjük.
A lerakat betöltésekor a rendszer ellenőrzi a kivonat integritását , majd az összes tanúsítványlánc visszafejtésre kerül. A titkos kulcsot csak kérésre dekódolják egy adott álnévvel, de a nyilvános tárhelyen titkosított állapotban marad. Az összes tanúsítványlánc titkosítása és a tárolási kivonat számítása csak akkor történik meg, ha a tárolót fájlba menti.
A tanúsítványláncokat helyi azonosítók társítják az üzleten belüli privát kulcsokhoz. A helyi azonosító egy UTF-8 bájtos tömb , amelyet úgy alakítanak ki, hogy a "Time" karakterláncból egy új kulcsot adnak hozzá, amelyet az elem hozzáadásának dátumának és időpontjának szöveges ábrázolása követ. Új kulcs hozzáadásakor a megfelelő tanúsítványlánc és jelszó is mindig megadásra kerül.
Az új titkos kulcs áttekinthető formában, vagy már titkosítva is beküldhető a tárolóhoz. Ez utóbbi esetben a kulcsjelszó nincs megadva.
A tároló nem tartalmazhat egyszerre GOST és nem GOST kulcsokat . A megfelelő belső tárolótípus betöltéskor vagy az első kulcs hozzáadásakor kerül beállításra. Ha a tároló üres, akkor a típusa ebben az értelemben nincs meghatározva.
A kulcselemek álneve általában nem kötelező. Ha van álnév nélküli elem a repository-ban, akkor az álnevet belső sorozatszám formájában erőszakosan hozzárendeli hozzá. A helyzet az, hogy a LirJSSE a Sun JSSE -hez hasonlóan csak álnevekkel dolgozik a tárolóelemekkel.
A tárolóelemek különböző programokkal történő létrehozásakor a titkosított elemek tárolásának belső struktúrája kissé eltérhet. Emiatt például ugyanaz a tanúsítványlánc csomagolható egy tárolófájlba LirSSL és LirJSSE használatával különböző méretű struktúrákba. A szabvány ezt lehetővé teszi, és ez nem befolyásolja a tároló funkcionalitását.
A JSSE használatakor ne felejtse el, hogy a kulcselemek jelszavainak meg kell egyeznie a tárolási jelszóval. A PKCS#12 szabvány általában több jelszót is engedélyez ugyanabban az áruházban, de a SunJSSE és a LirJSSE nem támogatja ezt a funkciót.
A Top Cross céggel kötött megállapodás alapján a teljes tárhely jelszavát a LirJSSE programban UTF-16 formátumba konvertálják használat előtt (az utolsó két bájt nulla). Az egyes tárolóelemeket pedig ugyanaz a jelszó védi, de UTF-8 formátumban .
A LirJSSE – Secure Sockets bővítmény GOST algoritmusokkal a Java számára összehasonlító leírást ad a PKCS#12 tárolófájlok belső szerkezetéről ASN.1 formátumban az RSA és GOST változatokhoz .