| PKCS#12 | |
|---|---|
| Extensie | .p12[1] sau [1].pfx |
| tip MIME | application/x-pkcs12 [1] |
| Dezvoltator | Securitate RSA [d] |
| publicat | 1996 |
| Ultima lansare |
PKCS #12 v1.0 (24 iunie 1999 Corrigendum tehnic 1 / 25 februarie 2000 ) |
| Tip de format | Arhiva |
| Conține | Certificate de cheie publică X.509 , chei private X.509 , CRL X.509 , date generice |
| Extins din | Format de fișier Microsoft PFX |
În criptografie , PKCS#12 este unul dintre Standardele Public-Key Criptography (PKCS) publicate de RSA Laboratories . Acesta definește formatul de fișier utilizat pentru stocarea și/sau transportul cheii private ( en:Private key ), lanțul de încredere de la certificatul utilizatorului la certificatul rădăcină al CA și lista de revocare a certificatelor (CRL). Fișierul este protejat în unul din două moduri: securizat, folosind o pereche de chei de încredere (chei publice/private potrivite pentru semnarea digitală și criptare) sau mai puțin sigur, folosind o cheie simetrică bazată pe parolă . Al doilea este potrivit pentru cazurile în care utilizarea perechilor de chei publice/private de încredere nu este disponibilă. Formatul PKCS#12 este un format conceput pentru a stoca o pereche de chei (cheie privată și certificat) care este recunoscută și utilizată de multe browsere și agenți de corespondență. Fișierele PKCS#12 stochează atât certificatul, cât și cheia privată (desigur, în formă criptată). Un exemplu de organizare a fișierelor PKCS#12 este prezentat în figura din dreapta.
Acest standard descrie sintaxa pentru transferul informațiilor personale de identificare, inclusiv chei private, certificate, diverse secrete și multe altele. Acest standard acceptă transferul direct de date între platforma de trimitere și platforma de primire. Standardul acceptă transferul de date atât cu un nivel ridicat de protecție (folosind o pereche de chei publică/privată utilizată pentru semnătura digitală și criptare), cât și cu un nivel mai scăzut de protecție (folosind autorizarea prin parolă), în cazul în care utilizarea unui /cheia cheie privată nu este disponibilă.
Standardul este implementat atât în hardware cât și în software. Un exemplu de implementare hardware sunt jetoanele securizate, cum ar fi Smart Card și PC Card .
Acest standard poate fi văzut ca o extensie a standardului PKCS8 . Sunt incluse informații suplimentare de identificare, inclusiv cheile private. A introdus un mod de securitate ridicată prin ascunderea cheii publice.
În urmă cu câțiva ani, sistemele criptografice erau folosite doar în cazuri excepționale: în organizații guvernamentale, agenții de informații și alte sisteme critice pentru securitatea datelor. Cu toate acestea, în prezent, dezvoltarea rapidă a rețelelor de calculatoare și a internetului face din ce în ce mai mulți oameni să se gândească la securitate. În zilele noastre, toată lumea este preocupată de securitatea datelor transmise prin rețea. Ca urmare, au apărut multe certificate și metode de criptare diferite . Acest articol va discuta formatul de stocare a cheilor PKCS#12 și unele dintre problemele asociate cu stocarea în siguranță a cheilor private ale certificatelor.
De-a lungul anilor, un număr mare de formate de stocare au fost create în plus față de formatele originale PKCS5 și PKCS8 , care au fost limitate la DES și MD5 . Acest lucru a dus la proliferarea formatelor de stocare a cheilor private incompatibile și adesea nesigure. Acest lucru a culminat cu formatul PKCS12 extrem de complex, cu amestecul său de identificatori de obiecte incompatibile, algoritmi, conținut de date și cerințe de procesare. Ca urmare a acestei confuzii, implementarea a fost atât nesigură, cât și incompatibilă cu versiunile mai vechi. Deoarece cerințele nu au furnizat suficiente informații pentru a implementa versiuni compatibile. O altă problemă cu acest format a fost umflarea datelor, ceea ce a făcut-o inutilă pentru utilizarea pe dispozitive cu memorie limitată, cum ar fi cardurile inteligente .
Aceste modificări au evidențiat nevoia de simplificare, securitate și interoperabilitate a formatelor de stocare a cheilor private. Sarcinile dezvoltatorilor pentru acest format au fost următoarele:
PKCS#12 este succesorul „PFX” de la Microsoft . Termenii „fișier PKCS#12” și „fișier PFX” sunt uneori folosiți interschimbabil.
PFX a fost puternic criticat pentru că este unul dintre cele mai complexe protocoale criptografice, dar rămâne singura modalitate standard astăzi de a stoca chei private și certificate într-un singur fișier criptat.
Netscape a folosit formatul PFX mai degrabă decât PKCS#12 în versiunile 4.03 și mai jos, deoarece formatul PKCS#12 pur și simplu nu exista. Datorită necesității de compatibilitate inversă, Netscape 4.04 și versiunile ulterioare, precum și toate versiunile de MSIE , au acceptat doar importurile PFX. Tabelul de mai jos rezumă cele de mai sus.
| Software | import PKCS#12 | Export PKCS#12 | Import PFX | Export PFX |
|---|---|---|---|---|
| Netscape 4.03 și versiuni anterioare | Da. | Da. | Da. | Da. |
| Netscape 4.04 și versiuni ulterioare | Da. | Da. | Da. | Da. |
| MSIE 4.0 și versiuni ulterioare | Da. | Da. | Da. | Da. |
SD
Orice combinație de moduri de confidențialitate și corectitudine este permisă în acest standard. Desigur, o bună politică de securitate presupune evitarea anumitor practici. De exemplu, ar fi o prostie să transmiteți o cheie privată fără nicio protecție fizică.
Pentru ambele moduri (confidențialitate și onestitate), este de preferat să folosiți o cheie publică decât o parolă. Cu toate acestea, nu este întotdeauna posibilă utilizarea modului folosind cheia publică. De exemplu, dacă în momentul trimiterii nu cunoaștem suficiente informații despre platforma destinatarului. În acest caz, modul care utilizează cheia publică va interfera doar.
Perechea de chei private/publice constă din două seturi de parametri. Setările publice cu informații suplimentare de identificare, cum ar fi numele de utilizator și adresele de e-mail, sunt stocate necriptate. Opțiunile private sunt în mare parte stocate folosind un fel de mecanism de protecție, cum ar fi criptarea.
Formatul containerului a fost definit pe baza formatului implementat în PKCS#7 și S/MIME . Următorul identificator de obiect identifică tipul de stocare securizată a conținutului cheii private.
id-securedPrivateKey IDENTIFICATOR DE OBIECT ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 42 }Tipul de stocare securizată a conținutului cheii private trebuie să fie de tipul ASN.1 SecuredPrivateKey :
SecuredPrivateKey ::= SEQUENCE { versiune Versiune, cheie publică, privateKey ContentInfo }Câmpurile de tip SecuredPrivateKey au următoarele semnificații:
versiune - numărul versiunii de sintaxă, trebuie să fie 0.
publicKey - Componenta publică a cheii și informații suplimentare de identificare despre proprietarul cheii.
privateKey este o cheie privată securizată constând din identificatorul tipului de conținut și conținutul în sine.
Componentele cheii publice sunt stocate în formă necriptată. Acest lucru se face deoarece nu există un motiv suficient de bun pentru a cripta aceste date. Deoarece criptarea acestor date cu orice criptare de flux expune atacatorul la o cantitate semnificativă de text cifrat cunoscut și pentru că trebuie să fie posibil ca utilizatorul să-și acceseze cheia publică fără să i se solicite o parolă. Informațiile despre cheia publică sunt reprezentate în tipul PublicKeyInfo :
PublicKeyInfo ::= ALEGEREA { publicKeyInfo SubjectPublicKeyInfo, -- Informații brute ale cheii publice certRequest [ 0 ] EXPLICIT PKCS10CertRequest, -- PKCS #10 cert.req. certificat [ 1 ] Certificat EXPLICIT, -- certificat X.509 certChain [ 2 ] EXPLICIT PKCS7CertChain—PKCS #7 cert.chain }În forma sa cea mai simplă, cheia publică este stocată ca SubjectPublicKeyInfo . Odată ce o solicitare de certificare a fost generată, informațiile „brute” ale cheii publice pot fi înlocuite după cum este necesar, iar atunci când cheia este certificată, poate fi stocat fie certificatul, fie cifrul complet al certificatului.
Componentele cheii private pot fi stocate fie în formă criptată, fie necriptată. Forma criptată este recomandată atâta timp cât datele nu sunt protejate prin alte mijloace. Dacă datele sunt stocate într-o formă necriptată, se utilizează tipul de conținut de date . Dacă datele sunt stocate în formă criptată, atunci tipul EncryptedData este utilizat cu contentEncryptionAlgorithm - algoritmul de criptare, modul și parametrii suplimentari care sunt utilizați la generarea cheii. Conținutul sau conținutul criptat al câmpurilor de cheie privată (fără câmpurile de cheie publică corespunzătoare) care se potrivesc cu câmpurile de cheie publică date în PublicKeyInfo.
De exemplu, pentru RSA :
RSAPrivateKey ::= SEQUENCE { privateExponent INTEGER, -- Exponent privat d prim1 INTEGER, -- Factorul prim p al lui n prim2 INTEGER, -- Factorul prim q al lui n exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coeficient INTEGER—coeficient CRT (q^-1) mod p }Pentru schema DSA și ElGamal :
DSAPrivateKey ::= SEQUENCE { x INTEGER—Număr întreg privat aleatoriu }Motivele pentru care sunt stocate numai câmpurile de cheie privată sunt: în primul rând, pentru a evita redundanța (tot cealaltă parte este deja conținut în PublicKeyInfo); în al doilea rând, pentru a elimina posibilitatea recuperării triviale a unei sume semnificative a fluxului de chei, folosind câmpuri publice cunoscute la începutul cheii.
PKCS#12 acceptă următorii algoritmi de criptare:
În plus, modul PKCS#5 v1.5 este de asemenea acceptat . Acest lucru vă permite să utilizați următorii algoritmi:
Utilizarea PKCS#5 v2.0 va permite utilizarea unui algoritm de criptare arbitrar.
OpenSSL poate gestiona PKCS#5 v1.5 și v2.0 în fișierele PKCS#12, dar alte implementări nu sunt acceptate.
Următorul tabel rezumă suportul pentru diferite criptări:
| Software și mod. | Criptare certificat | Criptare cu cheie privată |
|---|---|---|
| MSIE4 (versiuni interne și de export) Export PKCS#12. | RC2 pe 40 de biți . | RC2 pe 40 de biți . |
| MSIE4, 5 (versiuni interne și de export) import PKCS#12. | 40 biți RC2 , 3 chei 3DES . | 40 biți RC2 , 3 chei 3DES . |
| Export MSIE5 PKCS#12. | RC2 pe 40 de biți | 3DES cu 3 chei cu SHA1 (168 biți) |
| Netscape Communicator (versiuni interne și de export) Export PKCS#12 | RC2 pe 40 de biți | 3DES cu 3 chei cu SHA1 (168 biți) |
| Netscape Communicator (versiunea de export) PKCS#12 import. | Doar cifru de 40 de biți. | Toate. |
| Netscape Communicator (versiunea domestică sau fortificată) import PKCS#12. | Toate. | Toate. |
| Cod OpenSSL PKCS#12. | Toate. | Toate. |
În mod implicit, criptarea cea mai puternică este acceptată de toate implementările aplicației folosind PKCS#12: 3DES pentru cheile private și RC2-40 pentru certificate. De asemenea, opțiuni suplimentare vă permit să criptați certificatul folosind 3DES .
Trebuie remarcat faptul că, în timp ce mai multe versiuni de Netscape vor importa fișiere folosind algoritmi diferiți, în timp ce MSIE pare să accepte doar RC2 și 3DES .
Există mai multe mecanisme care permit transformarea parolei unui utilizator într-o cheie de criptare. Specificația PKCS#5 este limitată la iterațiile MD2 și MD5 pentru utilizare cu cheile DES .
Pentru a crea sau a converti un certificat, aveți nevoie de software- ul OpenSSL . Caracteristica SSL v3 este definită după cum urmează:
cheie = MD5(parolă + SHA1(„A” + parolă + sare)) + MD5(parolă + SHA1(„BB” + parolă + sare)) + MD5(parolă + SHA1(„CCC” + parolă + sare)) + ...suferă de faptul că intrarea folosită pentru pasul SHA-1 variază doar cu câțiva biți din intrarea utilizată în pasul anterior și că necesită utilizarea a două funcții diferite și fixe pentru a converti parola într-o cheie. În plus, funcția astfel definită nu permite procesarea iterabilă necesară pentru a preveni iterația dicționarului .
Funcția TLS extinde funcția SSL v3 și este definită după cum urmează:
cheie = HMAC(parolă, A(1) + sare) + HMAC(parolă, A(2) + sare) +...unde A(0) = sare este un număr arbitrar, A(1) = HMAC ( parolă , A(0)), …
(de fapt: cheia este XOR aplicată prin HMAC-MD5 și HMAC-SHA1 , din nou sunt necesari doi algoritmi fix diferiți). Un alt dezavantaj al utilizării HMAC este că dimensiunea parolei este limitată la 64 de caractere ASCII , sau 32 sau chiar 16 pentru un set de caractere mai larg, datorită cerinței de a reduce lungimea cheilor prin hashing. La fel ca și funcția SSL v3 , nu există nicio prevedere pentru repetarea funcției pentru a preveni repetarea în dicționar .
Funcția de derivare a cheii X.9-42 este definită în mod specific în termeni de SHA-1 :
cheie = SHA1(parola + 1) + SHA1(parola + 2) + ...Aceasta este probabil cea mai proastă funcție de derivare a cheii dintre toate, folosind o funcție hash fixă , schimbând doar un singur bit de intrare pentru fiecare bloc al cheii, introducând o cantitate mică de date modificate după setarea parolei, nu înainte și nu pot fi iterabile.
Aceste ipoteze propun următoarele cerințe pentru procesarea parolelor de utilizator:
Un alt obiectiv util de proiectare este de a face ieșirea dependentă de algoritmul de criptare; cheia este generată în așa fel încât să facă imposibile atacurile de recuperare a cheii . Dacă aceeași cheie este folosită pentru mai mulți algoritmi, atunci un atacator care poate obține cheia pentru un algoritm poate folosi acest atac în timp ce folosește alți algoritmi (de exemplu, obținerea unei chei DES vă permite să obțineți aproximativ jumătate din cheia IDEA ). A face ca rezultatul etapei de procesare a cheii să depindă de algoritmul de criptare, modul și configurația înseamnă că o cheie derivată din aceeași parolă folosind un alt mod sau algoritm de configurare nu va fi obținută cu ușurință.
Aceste cerințe sugerează următorul design de bază:
cheie[] = {0}; stare = hash( algoritm, mod, parametri, sare, parola); pentru count = 1 la iterații pentru lungime = 1 la keyLength stare = hash(stare); cheie[ lungime ] ^= hash( stare, parola );Starea internă depinde de toți parametrii de intrare (algoritm de criptare, mod, parametri, sare și, desigur, parola). Apoi, la fiecare pas de procesare, variabilele de stare acționează ca un generator de numere pseudoaleatoare , care asigură că parametrii de intrare ai funcției hash utilizate la generarea cheii sunt modificați cu un număr de biți egal cu ieșirea funcției hash la fiecare pas și asigură că procesul de obținere a cheii de către utilizator este liniar, adică nu este posibilă nicio formă de paralelizare sau precalculare. În cele din urmă, prin XOR ieșirea unui pas de procesare de succes, iar cheia la fiecare iterație contribuie la cheia rezultată.
Parametrii de intrare pentru funcția hash utilizate pentru a genera variabile de stare:
StateHashData ::= SEQUENCE { encryptionAlgorithm AlgorithmIdentifier, sare OCTET DIMENSIUNE ȘIR (8) OPȚIONAL, parola UTF8String }Câmpurile de tip StateHashData au următoarele semnificații:
encryptionAlgorithm — algoritm de criptare, mod și parametri suplimentari necesari pentru a genera cheia. Implementarea trebuie să accepte 3DES-CBC .
sarea este un număr aleator de 64 de biți. Această valoare poate fi neglijată dacă este necesar să se obțină o cheie constantă pentru o anumită parolă.
parola este parola utilizatorului, reprezentată de un șir UTF8 .
Parametrii de intrare ai funcției hash utilizate pentru obținerea cheii:
KeyHashData ::= SEQUENCE { stare OCTET STRING, parola UTF8String }starea este rezultatul unei funcții hash bazată pe un generator de numere aleatorii .
parola este parola utilizatorului, reprezentată de un șir UTF8 .
Când este utilizat tipul EncryptedData , atunci conținutul contentEncryptionAlgorithm este identificat după cum urmează:
id-passwordBasedEncryption IDENTIFICATOR DE OBIECT ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 43}
Opțiuni relevante:
PBEParameters ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, encryptionAlgorithm AlgorithmIdentifier, sare OCTET STRING SIZE(8), iterationCount INTEGER(200...MAX_ITERATION) }Câmpurile de tip PBEParameters au următoarele semnificații:
hashAlgorithm - algoritmul hash utilizat pentru a procesa parola. Implementarea trebuie să accepte SHA-1 și, de preferință, să accepte MD5 și RIPEMD-160 .
encryptionAlgorithm este algoritmul utilizat pentru a genera cheia și pentru a cripta datele. Are același sens ca în StateHashData .
slat - are același sens ca în StateHashData .
iterationCount - numărul de iterații hash de efectuat. Pentru o securitate rezonabilă, se recomandă utilizarea a aproximativ 500 de operații, care durează mai puțin de o secundă pe o stație de lucru tipică.
Cu toate acestea, acest lucru nu este valabil nici pentru obiectele certificat. Motivul pentru aceasta este că asigurarea integrității fișierelor PKCS#12 este opțională, așa cum se arată aici:
PFX ::= SEQUENCE { versiunea INTEGER {v3(3)}(v3,...), authSafe ContentInfo, macData MacData OPȚIONAL }Deoarece acest control este opțional, acesta poate fi dezactivat și apoi conținutul fișierului poate fi modificat fără detectare sau avertizare. Prin urmare, controlul accesului nu este necesar pentru a adăuga obiecte de certificat. În acest caz, certificatele sunt utilizate în SSL PKI ca o ancora de încredere și acest lucru permite unui atacator să insereze ancora de încredere a CA lor în aceste fișiere fără a fi nevoie de nicio autorizație.
Odată ce Ancora de încredere a atacatorului este inserată în sistemul atacat, acesta va avea încredere și va recunoaște orice certificat emis de CA a atacatorului.
Atacul poate fi un atac de tip om-in-the-middle care interceptează fișierele în timpul tranzitului, inserând o Ancoră de încredere inamică . În acest caz, atacul ar putea funcționa la fel de bine împotriva sistemelor care nu folosesc fișiere PKCS#12, cum ar fi depozitul de chei, dar acest atac are dezavantajul că un certificat fals poate fi detectat odată ce atacul este descoperit.
Extensie de fișier : „.p12” sau „.pem”. Aceste fișiere pot fi create cu OpenSSL .
Pe baza articolului: Crearea certificatelor PKCS12
Configurarea mediuluiCreați un director (de exemplu, certificat) și schimbați-l în el. Creați un fișier certindex.txt gol în el Rulați comenzile:
mkdir privat mkdir certs echo '100001' > serial atinge certindex.txtÎn acest director, creați fișierul de configurare openssl.conf cu următorul conținut:
# # Fișier de configurare OpenSSL. # # Stabiliți directorul de lucru. dir = . [ca] default_ca = CA_default [CA_default] serial = $dir/serial baza de date = $dir/certindex.txt new_certs_dir = $dir/certs certificat = $dir/cacert.pem cheie_privată = $dir/private/cakey.pem default_days = 365 default_md=md5 conserva = nu email_in_dn = nr nameopt = default_ca certopt=default_ca policy = policy_match [policy_match] countryName = potrivire stateOrProvinceName = potrivire organizationName = potrivire organizationalUnitName = opțional commonName = furnizat emailAddress = opțional [req] default_bits = 1024 # Dimensiunea tastelor default_keyfile = key.pem # numele cheilor generate default_md = md5 # algoritm de digest mesaj string_mask = nombstr # caractere permise nume_distins = req_distinguished_name req_extensions = v3_req [ req_distinguished_name ] # Nume variabilă șir prompt #-------------------------------- ----------------- ------- ---------- 0.organizationName = Numele organizației (companie) organizationalUnitName = Numele unității organizaționale (departament, divizie) emailAddress = EmailAddress emailAddress_max = 40 localityName = LocalityName (oraș, district) stateOrProvinceName = Numele statului sau al provinciei (nume complet) countryName = CountryName (cod cu două litere) countryName_min = 2 countryName_max = 2 commonName = Nume comun (nume de gazdă, IP sau numele dvs.) commonName_max = 64 # Valori implicite pentru cele de mai sus, pentru consecvență și mai puțină tastare. # Nume variabilă Valoare #------------------------ ------------------------- ----- 0.organizationName_default = Companie localityName_default = Moscova stateOrProvinceName_default = Moscova countryName_default = RU emailAddress_default = [email protected] commonName_default = text comun [v3_ca] basicConstraints = CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always [v3_req] basicConstraints = CA:FALSE subjectKeyIdentifier = hash Generarea unui certificat de autoritate de certificare openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.confCând vi se solicită o parolă, vă rugăm să furnizați o parolă de cel puțin 4 caractere. Pentru toate celelalte interogări, puteți apăsa Enter .
Crearea unui certificat de utilizatorMai întâi, să setăm un nume pentru fișierele de certificate ale utilizatorului. Deoarece pot fi multe, setarea acesteia printr-o variabilă de mediu vă va permite să repetați acest pas foarte rapid pentru fiecare utilizator.
nume='utilizator'Acum creăm un certificat PKCS12 pentru fiecare utilizator. Rulați câte o comandă:
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 "descriere" -out $name-cert.p12Când vi se solicită o parolă, utilizați parola care a fost setată când ați creat certificatul CA. Pentru toate celelalte interogări, puteți apăsa Enter .
Fișier terminat: user-cert.p12
Acest fișier poate fi importat în Firefox sau Thunderbird și apoi utilizat în OpenOffice.org.
Să presupunem că trebuie să creăm un fișier cert.p12 . Să presupunem că avem fișiere cu chei private prkey.pem și un fișier certificat cert.pem . Puteți face acest lucru cu comanda openssl pkcs12 :
openssl pkcs12 -export -in cert.pem -inkey prkey.pem -name „Certificatul meu” -out cert.p12unde -name este cheia care specifică ID-ul certificatului dumneavoastră. Astfel, în exemplul nostru, șirul „Certificatul meu” va fi afișat în programul utilizatorului. Când încercați să accesați certificatul, vi se va cere mai întâi să introduceți parola pentru cheia privată curentă și apoi parola pentru fișierul PKCS#12 (*.p12). Mai mult, parola din fișierul PKCS # 12 va fi solicitată de două ori.
După o anumită perioadă de timp, certificatul devine invalid. Dacă acesta este certificatul unui angajat, atunci, de exemplu, după concedierea acestuia, certificatul trebuie considerat invalid. Dacă cheia privată a certificatului a devenit publică din orice motiv, atunci trebuie adăugată și la lista de certificate invalide (CRL). Puteți utiliza comanda openssl ca pentru a gestiona CRL-ul .
Crearea CRL-urilor:
openssl ca -gencrl -out crl.pemAdăugarea de certificate inutile se face folosind comanda:
openssl ca -revoke bad_cert.pemDupă fiecare aplicare de revocare, este necesar să actualizați CRL-ul cu comanda
openssl ca -gencrlMai multe informații pot fi găsite în manual folosind comanda man pkcs12 din terminalul Linux sau linkul pkcs12(1) .
Această secțiune se bazează pe LirJSSE, o extensie de suport pentru algoritmul GOST Secure Sockets pentru Java . Pentru mai multe informații despre cum este implementat PKCS#12 în biblioteca JSSE , consultați sursa.
Furnizorul SunJSSE oferă o implementare completă a formatului PKCS#12 java.security.KeyStore pentru citirea și scrierea fișierelor pkcs12. Acest format este acceptat și de alte instrumente și aplicații pentru importarea și exportul cheilor și certificatelor, cum ar fi Netscape / Mozilla , Microsoft Internet Explorer și OpenSSL . De exemplu, aceste implementări pot exporta certificate și chei client într-un fișier cu extensia „.p12”.
Cu furnizorul LirJSSE , puteți obține chei PKCS#12 prin API-ul KeyStore cu tipul de magazin „pkcs12”. În plus, puteți vizualiza lista cheilor instalate și certificatele corespunzătoare utilizând comanda keytool cu opțiunea -storetype setată la pkcs12.
Pentru orice eventualitate, trebuie să rețineți că în Java 6 JDK aceleași clase de suport pentru stocare PKCS#12 sunt conținute nu numai în JSSE , ci și separat în pachetul sun.security.pkcs12 .
Implementarea stocării PKCS#12 în LirJSSE acceptă în plus algoritmi GOST. În cele ce urmează sunt descrise caracteristicile acestei implementări.
Când depozitul este încărcat, integritatea lui digest este verificată , după care toate lanțurile de certificate sunt decriptate. Cheia secretă este decriptată numai la cerere cu un alias specific, dar rămâne în starea criptată în stocarea publică. Criptarea tuturor lanțurilor de certificate și calculul rezumatului de stocare sunt efectuate numai atunci când stocarea este salvată într-un fișier.
Lanțurile de certificate sunt asociate cu chei private din magazin prin identificatori locali. Identificatorul local este o matrice UTF-8 octeți format prin adăugarea unei noi chei din șirul „Ora” urmată de o reprezentare textuală a datei și orei la care a fost adăugat elementul. Când este adăugată o cheie nouă, lanțul de certificate și parola corespunzătoare sunt întotdeauna specificate.
Noua cheie secretă poate fi trimisă pentru a fi adăugată în seif în formă clară sau deja criptată. În acest din urmă caz, parola cheii nu este specificată.
Seiful nu poate conține atât chei GOST , cât și chei non- GOST în același timp . Tipul de stocare internă corespunzător este setat fie când este încărcat, fie când este adăugată prima cheie. Dacă depozitul este gol, atunci tipul său nu este definit în acest sens.
Un alias pentru un element cheie este, în general, opțional. Dacă există un element fără alias în depozit, atunci aliasul îi este atribuit forțat sub forma unui număr de serie intern. Cert este că LirJSSE , ca și Sun JSSE , funcționează cu elemente de stocare numai prin alias.
Când se creează elemente de stocare prin diferite programe, structura internă a stocării elementelor criptate poate diferi ușor. Din această cauză, de exemplu, același lanț de certificate poate fi împachetat într-un fișier de stocare folosind LirSSL și LirJSSE în structuri de diferite dimensiuni. Standardul permite acest lucru și nu afectează funcționalitatea depozitului.
Când lucrați cu JSSE , nu uitați că parolele elementelor cheie trebuie să se potrivească cu parola de stocare. Standardul PKCS#12 permite în general mai multe parole în același magazin, dar SunJSSE și LirJSSE nu acceptă această caracteristică.
Prin acord cu compania Top Cross, parola întregii stocări este convertită în programul LirJSSE în format UTF-16 înainte de utilizare (ultimii doi octeți sunt zero). Și elementele de stocare individuale sunt protejate de aceeași parolă, dar în format UTF-8 .
LirJSSE - Secure Sockets Extension with GOST Algorithms pentru Java oferă o descriere comparativă a structurii interne a fișierelor de stocare PKCS#12 în format ASN.1 pentru variantele RSA și GOST .