| PKCS#12 | |
|---|---|
| Förlängning | .p12[1] eller [1].pfx |
| MIME -typ | application/x-pkcs12 [1] |
| Utvecklaren | RSA-säkerhet [d] |
| publiceras | 1996 |
| Senaste släppningen |
PKCS #12 v1.0 (24 juni 1999 Teknisk rättelse 1 / 25 februari 2000 ) |
| Formattyp | Arkiv |
| Innehåller | X.509 offentliga nyckelcertifikat , X.509 privata nycklar , X.509 CRL:er , generisk data |
| Utökad från | Microsoft PFX-filformat |
Inom kryptografi är PKCS#12 en av Public-Key Cryptography Standards (PKCS) som publiceras av RSA Laboratories . Den definierar filformatet som används för att lagra och/eller transportera den privata nyckeln ( sv:Private nyckel ), förtroendekedjan från användarens certifikat till CA:s rotcertifikat och listan över återkallande av certifikat (CRL). Filen är skyddad på ett av två sätt: säker, med ett betrodd nyckelpar (offentliga/privata nycklar lämpliga för digital signering och kryptering) eller mindre säker, med en lösenordsbaserad symmetrisk nyckel . Den andra är lämplig för fall där användningen av betrodda offentliga/privata nyckelpar inte är tillgänglig. PKCS#12-formatet är ett format utformat för att lagra ett nyckelpar (privat nyckel och certifikat) som känns igen och används av många webbläsare och e-postagenter. PKCS#12-filer lagrar både certifikatet och den privata nyckeln (naturligtvis i krypterad form). Ett exempel på PKCS#12-filorganisation visas i bilden till höger.
Den här standarden beskriver syntaxen för överföring av personlig identifieringsinformation, inklusive privata nycklar, certifikat, olika hemligheter och mer. Denna standard stöder direkt dataöverföring mellan den sändande plattformen och den mottagande plattformen. Standarden stöder överföring av data med både en hög skyddsnivå (med ett offentligt/privat nyckelpar som används för digital signatur och kryptering) och en lägre skyddsnivå (med lösenordsauktorisering), i händelse av att användningen av en offentlig /privat nyckelnyckel är inte tillgänglig.
Standarden är implementerad både i hårdvara och mjukvara. Ett exempel på en hårdvaruimplementering är säkra tokens som Smart Card och PC Card .
Denna standard kan ses som en förlängning av PKCS8- standarden . Ytterligare identifieringsinformation ingår, inklusive privata nycklar. Introducerade ett högsäkerhetsläge genom att dölja den publika nyckeln.
För några år sedan användes kryptosystem endast i undantagsfall: i statliga organisationer, underrättelsetjänster och andra system som är kritiska för datasäkerhet. Men i dagsläget gör den snabba utvecklingen av datornätverk och internet fler och fler människor att tänka på säkerhet. Nuförtiden är alla oroade över säkerheten för data som överförs över nätverket. Som ett resultat har många olika certifikat och krypteringsmetoder dykt upp . Den här artikeln kommer att diskutera nyckellagringsformatet PKCS#12 och några av de problem som är förknippade med säker lagring av privata certifikatnycklar.
Under årens lopp har ett stort antal lagringsformat skapats utöver de ursprungliga PKCS5- och PKCS8- formaten , som var begränsade till DES och MD5 . Detta har lett till spridningen av inkompatibla och ofta osäkra privata nyckellagringsformat. Detta kulminerade i det extremt komplexa PKCS12-formatet, med dess blandning av inkompatibla objektidentifierare, algoritmer, datainnehåll och bearbetningskrav. Som ett resultat av denna förvirring var implementeringen både osäker och inkompatibel med äldre versioner. Eftersom kraven inte gav tillräckligt med information för att implementera kompatibla versioner. Ett annat problem med det här formatet var datauppblåsthet, vilket gjorde det oanvändbart för användning i minnesbegränsade enheter som smartkort .
Dessa ändringar lyfte fram behovet av förenkling, säkerhet och interoperabilitet för lagringsformat för privata nyckel. Utvecklarnas uppgifter för detta format var följande:
PKCS#12 är efterföljaren till "PFX" från Microsoft . Termerna "PKCS#12-fil" och "PFX-fil" används ibland omväxlande.
PFX har kritiserats hårt för att vara ett av de mest komplexa kryptografiska protokollen men är fortfarande det enda standardsättet idag att lagra privata nycklar och certifikat i en enda krypterad fil.
Netscape använde PFX-formatet snarare än PKCS#12 i version 4.03 och senare eftersom PKCS#12-formatet helt enkelt inte existerade. På grund av behovet av bakåtkompatibilitet, stödde Netscape 4.04 och senare, och alla versioner av MSIE , endast PFX-import. Tabellen nedan sammanfattar ovanstående.
| programvara | PKCS#12 import | PKCS#12 export | PFX import | PFX export |
|---|---|---|---|---|
| Netscape 4.03 och tidigare | Ja. | Ja. | Ja. | Ja. |
| Netscape 4.04 och senare | Ja. | Ja. | Ja. | Ja. |
| MSIE 4.0 och senare | Ja. | Ja. | Ja. | Ja. |
SD
Alla kombinationer av integritets- och rättviselägen är tillåtna i denna standard. En bra säkerhetspolicy innebär naturligtvis att man undviker vissa metoder. Det skulle till exempel vara dumt att överföra en privat nyckel utan något fysiskt skydd.
För båda lägena (sekretess och ärlighet) är det att föredra att använda en offentlig nyckel snarare än ett lösenord. Det är dock inte alltid möjligt att använda läget med den publika nyckeln. Till exempel om vi vid tidpunkten för sändningen inte känner till tillräckligt med information om mottagarens plattform. I det här fallet kommer läget som använder den publika nyckeln bara att störa.
Det privata/offentliga nyckelparet består av två uppsättningar parametrar. Offentliga inställningar med ytterligare identifierande information som användarnamn och e-postadresser lagras okrypterat. Privata alternativ lagras oftast med hjälp av någon form av skyddsmekanism som kryptering.
Behållarformatet definierades baserat på formatet implementerat i PKCS#7 och S/MIME . Följande objektidentifierare identifierar den säkra lagringstypen för innehållet i den privata nyckeln.
id-securedPrivateKey OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 42 }Den säkra lagringstypen för innehållet med den privata nyckeln måste vara av typen ASN.1 SecuredPrivateKey :
SecuredPrivateKey ::= SEQUENCE { version version, publicKey, privateKey ContentInfo }Fält av typen SecuredPrivateKey har följande betydelser:
version – syntaxversionsnummer, måste vara 0.
publicKey - Den offentliga komponenten av nyckeln och ytterligare identifieringsinformation om nyckelns ägare.
privateKey är en säker privat nyckel som består av innehållstypsidentifieraren och själva innehållet.
De offentliga nyckelkomponenterna lagras i okrypterad form. Detta görs eftersom det inte finns någon tillräckligt bra anledning att kryptera denna data. Eftersom kryptering av denna data med vilket strömchiffer som helst exponerar angriparen för en betydande mängd känd chiffertext, och eftersom det måste vara möjligt för användaren att komma åt sin publika nyckel utan att bli tillfrågad om ett lösenord. Information om offentlig nyckel representeras i typen PublicKeyInfo :
PublicKeyInfo ::= CHOICE { publicKeyInfo SubjectPublicKeyInfo, -- Rå offentlig nyckelinformation certRequest [ 0 ] EXPLICIT PKCS10CertRequest, -- PKCS #10 cert.req. certifikat [ 1 ] EXPLICIT certifikat, -- X.509 certifikat certChain [ 2 ] EXPLICIT PKCS7CertChain—PKCS #7 cert.chain }I sin enklaste form lagras den publika nyckeln som en SubjectPublicKeyInfo . När en certifieringsbegäran har genererats kan den "råa" offentliga nyckelinformationen ersättas efter behov och när nyckeln är certifierad kan antingen certifikatet eller hela certifikatchifferet lagras.
De privata nyckelkomponenterna kan lagras i antingen krypterad eller okrypterad form. Det krypterade formuläret rekommenderas så länge som uppgifterna inte skyddas på annat sätt. Om data lagras i okrypterad form används innehållstypen Data . Om data lagras i krypterad form, används typen EncryptedData med contentEncryptionAlgorithm - krypteringsalgoritmen, läget och ytterligare parametrar som används när nyckeln genereras. Innehållet eller det krypterade innehållet i de privata nyckelfälten (utan motsvarande offentliga nyckelfält) som matchar de offentliga nyckelfälten som anges i PublicKeyInfo.
Till exempel, för RSA :
RSAPrivateKey ::= SEKVENS { privateExponent INTEGER, -- Privat exponent d prime1 HELTAL, -- Primfaktor p av n prime2 HELTAL, -- Primfaktor q av n exponent1 HELTAL, -- d mod (p-1) exponent2 HELTAL, -- d mod (q-1) koefficient INTEGER—CRT-koefficient (q^-1) mod sid }För DSA och ElGamal-schema :
DSAPrivateKey ::= SEKVENS { x INTEGER—Privat slumpmässigt heltal }Anledningarna till att endast privata nyckelfält lagras är: för det första för att undvika redundans (allt annat finns redan i PublicKeyInfo); för det andra, för att eliminera möjligheten till trivial återvinning av en betydande summa av nyckelströmmen, genom att använda kända publika fält i början av nyckeln.
PKCS#12 stöder följande krypteringsalgoritmer:
Dessutom stöds även PKCS#5 v1.5- läge . Detta låter dig använda följande algoritmer:
Användning av PKCS#5 v2.0 tillåter användning av en godtycklig krypteringsalgoritm.
OpenSSL kan hantera PKCS#5 v1.5 och v2.0 i PKCS#12-filer, men andra implementeringar stöds inte.
Följande tabell sammanfattar stödet för olika krypteringar:
| Programvara och läge. | Certifikatkryptering | Privat nyckelkryptering |
|---|---|---|
| MSIE4 (inhemska och exportversioner) PKCS#12 export. | 40 bitars RC2 . | 40 bitars RC2 . |
| MSIE4, 5 (inhemska och exportversioner) PKCS#12 import. | 40 bitars RC2 , 3-nyckel 3DES . | 40 bitars RC2 , 3-nyckel 3DES . |
| MSIE5 PKCS#12 export. | 40 bitars RC2 | 3-nyckel 3DES med SHA1 (168 bitar) |
| Netscape Communicator (inhemska och exportversioner) PKCS#12 export | 40 bitars RC2 | 3-nyckel 3DES med SHA1 (168 bitar) |
| Netscape Communicator (exportversion) PKCS#12-import. | Endast 40 bitars chiffer. | Allt. |
| Netscape Communicator (inhemsk eller befäst version) PKCS#12-import. | Allt. | Allt. |
| OpenSSL PKCS#12-kod. | Allt. | Allt. |
Som standard stöds den starkaste krypteringen av alla applikationsimplementeringar som använder PKCS#12: 3DES för privata nycklar och RC2-40 för certifikat. Ytterligare alternativ låter dig också kryptera certifikatet med 3DES .
Det bör noteras att medan flera versioner av Netscape kommer att importera filer med olika algoritmer, medan MSIE bara verkar stödja RC2 och 3DES .
Det finns flera mekanismer som gör det möjligt att omvandla en användares lösenord till en krypteringsnyckel. PKCS #5- specifikationen är begränsad till MD2- och MD5- iterationer för användning med DES- nycklar .
För att skapa eller konvertera ett certifikat behöver du programvaran OpenSSL . SSL v3 -funktionen definieras enligt följande:
nyckel = MD5(lösenord + SHA1(“A” + lösenord + salt)) + MD5(lösenord + SHA1(“BB” + lösenord + salt)) + MD5(lösenord + SHA1(“CCC” + lösenord + salt)) + ...lider av att ingången som används för SHA-1- steget endast varierar med några få bitar av ingången som användes i föregående steg och att det krävs användning av två olika och fasta funktioner för att konvertera lösenordet till en nyckel. Dessutom tillåter den sålunda definierade funktionen inte den itererbara bearbetningen som är nödvändig för att förhindra ordboksiteration .
TLS- funktionen utökar SSL v3- funktionen och definieras enligt följande:
nyckel = HMAC(lösenord, A(1) + salt) + HMAC(lösenord, A(2) + salt) + ...där A(0) = salt är ett godtyckligt tal, A(1) = HMAC ( lösenord , A(0)), …
(som ett faktum: nyckeln är XOR applicerad via HMAC-MD5 och HMAC-SHA1 , återigen två olika fasta algoritmer krävs). En annan nackdel med att använda HMAC är att lösenordsstorleken är begränsad till 64 ASCII- tecken, eller 32 eller till och med 16 för en bredare teckenuppsättning, på grund av kravet att minska längden på nycklar genom att hasha dem. Precis som SSL v3- funktionen finns det ingen möjlighet att iterera funktionen för att förhindra iteration över ordboken .
X.9-42- nyckelhärledningsfunktionen definieras specifikt i termer av SHA-1 :
nyckel = SHA1(lösenord + 1) + SHA1(lösenord + 2) + ...Detta är förmodligen den sämsta nyckelhärledningsfunktionen av alla, med hjälp av en fast hash-funktion , ändrar endast en enda ingångsbit för varje block av nyckeln, introducerar en liten mängd ändrad data efter att lösenordet har ställts in, inte tidigare och inte iterabel.
Dessa antaganden anger följande krav för bearbetning av användarlösenord:
Ett annat användbart designmål är att göra utdata beroende av krypteringsalgoritmen; nyckeln genereras på ett sådant sätt att det omöjliggör attacker för nyckelåterställning . Om samma nyckel används för flera algoritmer kan en angripare som kan erhålla nyckeln för en algoritm använda denna attack samtidigt som andra algoritmer används (om du till exempel skaffar en DES- nyckel kan du få ungefär hälften av IDEA- nyckeln ). Att göra resultatet av nyckelbearbetningssteget beroende av krypteringsalgoritmen, läget och konfigurationen innebär att en nyckel som härrör från samma lösenord med användning av ett annat läge eller konfigurationsalgoritm inte kommer att erhållas lätt.
Dessa krav föreslår följande grundläggande design:
nyckel[] = { 0 }; state = hash(algoritm, läge, parametrar, salt, lösenord ); för räkning = 1 till iterationer för längd = 1 till keyLength tillstånd = hash(tillstånd); nyckel[ längd ] ^= hash(tillstånd, lösenord);Det interna tillståndet beror på alla ingångsparametrar (krypteringsalgoritm, läge, parametrar, salt och, naturligtvis, lösenordet). Sedan, vid varje bearbetningssteg, fungerar tillståndsvariablerna som en pseudoslumptalsgenerator , som säkerställer att ingångsparametrarna för hashfunktionen som används för att generera nyckeln ändras med ett antal bitar lika med utmatningen av hashfunktionen vid varje steg, och säkerställer att processen för att erhålla nyckeln av användaren är linjär, d.v.s. någon form av parallellisering eller förberäkning är inte möjlig. I slutändan, genom att XORing utmatningen av ett framgångsrikt bearbetningssteg, och nyckeln vid varje iteration bidrar till den resulterande nyckeln.
Inmatningsparametrar för hashfunktionen som används för att generera tillståndsvariabler:
StateHashData ::= SEKVENS { encryptionAlgorithm AlgorithmIdentifier, salt OCTET STRING STORLEK(8) VALFRI, lösenord UTF8String }Fält av typen StateHashData har följande betydelser:
encryptionAlgorithm — krypteringsalgoritm, läge och ytterligare parametrar som behövs för att generera nyckeln. Implementeringen måste stödja 3DES-CBC .
salt är ett 64-bitars slumptal. Detta värde kan försummas om det är nödvändigt att erhålla en nyckel som är konstant för ett givet lösenord.
lösenord är användarens lösenord, representerat av en UTF8-sträng .
Inmatningsparametrar för hashfunktionen som används för att erhålla nyckeln:
KeyHashData ::= SEKVENS { ange OCTET STRING, lösenord UTF8String }state är resultatet av en hashfunktion baserad på en slumptalsgenerator .
lösenord är användarens lösenord, representerat av en UTF8-sträng .
När typen EncryptedData används identifieras innehållet i contentEncryptionAlgorithm enligt följande:
id-passwordBasedEncryption OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 43}
Relevanta alternativ:
PBEparametrar ::= SEKVENS { hashAlgorithm AlgorithmIdentifier, encryptionAlgorithm AlgorithmIdentifier, salt OCTET STRING STORLEK(8), iterationCount INTEGER(200...MAX_ITERATION) }Fält av typen PBEParametrar har följande betydelser:
hashAlgorithm - hashalgoritmen som används för att bearbeta lösenordet. Implementeringen måste stödja SHA-1 och helst stödja MD5 och RIPEMD-160 .
encryptionAlgorithm är den algoritm som används för att generera nyckeln och för att kryptera data. Har samma betydelse som i StateHashData .
slat - har samma betydelse som i StateHashData .
iterationCount – antalet hash-iterationer som ska utföras. För rimlig säkerhet rekommenderas det att använda cirka 500 operationer, som tar mindre än en sekund på en vanlig arbetsstation.
Detta gäller dock inte heller för certifikatobjekt. Anledningen till detta är att det är valfritt att säkerställa integriteten för PKCS#12-filer, som visas här:
PFX ::= SEQUENCE { version INTEGER {v3(3)}(v3,...), authSafe ContentInfo, macData MacData VALFRITT }Eftersom denna kontroll är valfri kan den inaktiveras och sedan kan innehållet i filen ändras utan upptäckt eller varning. Därför krävs inte åtkomstkontroll för att lägga till certifikatobjekt. I det här fallet används certifikaten i SSL PKI som ett förtroendeankare , och detta gör att en angripare kan infoga sin CAs förtroendeankare i dessa filer utan behov av någon auktorisering.
När angriparens förtroendeankare väl har infogats i det attackerade systemet kommer det att lita på och känna igen alla certifikat som utfärdats av angriparens CA.
Attacken kan vara en man-in-the-midten- attack som fångar upp filer under transporten och sätter in en fiende Trust Anchor . I det här fallet kan attacken lika gärna fungera mot system som inte använder PKCS#12-filer som keystore, men denna attack har nackdelen att ett falskt certifikat kan upptäckas när attacken upptäcks.
Filtillägg : ".p12" eller ".pem". Dessa filer kan skapas med OpenSSL .
Baserat på artikeln: Skapa PKCS12-certifikat
Ställa in miljönSkapa en katalog (t.ex. certifikat) och byt till den. Skapa en tom certindex.txt -fil i den Kör kommandona:
mkdir privat mkdir-certifikat echo '100001' > seriell tryck på certindex.txtSkapa konfigurationsfilen openssl.conf med följande innehåll i den här katalogen:
# # OpenSSL-konfigurationsfil. # # Etablera arbetskatalog. dir = . [ca] default_ca = CA_default [CA_default] seriell = $dir/seriell databas = $dir/certindex.txt new_certs_dir = $dir/certs certifikat = $dir/cacert.pem private_key = $dir/private/cakey.pem default_days = 365 default_md=md5 bevara = nej email_in_dn = nej nameopt = default_ca certopt=default_ca policy = policy_match [policy_match] countryName = matchning stateOrProvinceName = matchning organisationName = match organisationalUnitName = valfritt commonName = tillhandahålls e-postadress = valfritt [req] default_bits = 1024 # Storlek på nycklar default_keyfile = key.pem # namn på genererade nycklar default_md = md5 # meddelandesammanfattningsalgoritm string_mask = nombstr # tillåtna tecken distinguished_name = req_distinguished_name req_extensions = v3_req [req_distinguished_name] # Variabelnamn Promptsträng #------------------------------------------------ ------- ---------- 0.organizationName = Organisationsnamn (företag) organisationalUnitName = Organisationsenhetsnamn (avdelning, division) emailAddress = EmailAddress emailAddress_max = 40 localityName = LocalityName (stad, distrikt) stateOrProvinceName = Stats- eller provinsnamn (fullständigt namn) countryName = CountryName (kod på två bokstäver) countryName_min = 2 countryName_max = 2 commonName = Common Name (värdnamn, IP eller ditt namn) commonName_max = 64 # Standardvärden för ovanstående, för konsekvens och mindre skrivning. # Variabelnamn Värde #------------------------ -------------------------- ----- 0.organisationName_default = Företag localityName_default = Moskva stateOrProvinceName_default = Moskva countryName_default = RU emailAddress_default = [email protected] commonName_default = vanlig text [v3_ca] basicConstraints = CA:TRUE subjectKeyIdentifier = hash AuthorityKeyIdentifier = nyckel-id: alltid, utfärdare: alltid [v3_req] basicConstraints = CA:FALSE subjectKeyIdentifier = hash Generera ett certifieringsmyndighetscertifikat openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.confNär du uppmanas att ange ett lösenord, vänligen ange ett lösenord på minst 4 tecken. För alla andra frågor kan du trycka på Enter .
Skapa ett användarcertifikatLåt oss först ange ett namn för användarens certifikatfiler. Eftersom det kan vara många, kan du genom att ställa in den via en miljövariabel upprepa detta steg mycket snabbt för varje användare.
name='användare'Nu skapar vi ett PKCS12-certifikat för varje användare. Kör ett kommando i taget:
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 -infiler $name-req.pem openssl pkcs12 -export -in $name-cert.pem -inkey privat/$name-key.pem -certfile cacert.pem -name "description" -out $name-cert.p12När du uppmanas att ange ett lösenord, använd lösenordet som angavs när du skapade CA-certifikatet. För alla andra frågor kan du trycka på Enter .
Färdig fil: user-cert.p12
Den här filen kan importeras till Firefox eller Thunderbird och sedan användas i OpenOffice.org.
Låt oss säga att vi behöver skapa en cert.p12 -fil . Låt oss säga att vi har privata nyckelfiler prkey.pem och en certifikatfil cert.pem . Du kan göra detta med kommandot openssl pkcs12 :
openssl pkcs12 -export -in cert.pem -inkey prkey.pem -name "Mitt certifikat" -out cert.p12där -name är nyckeln som anger ditt certifikats ID. I vårt exempel kommer alltså strängen "Mitt certifikat" att visas i användarprogrammet. När du försöker komma åt certifikatet blir du först ombedd att ange lösenordet för den aktuella privata nyckeln och sedan lösenordet för PKCS#12-filen (*.p12). Dessutom kommer lösenordet från PKCS #12-filen att begäras två gånger.
Efter en viss tid blir certifikatet ogiltigt. Om det rör sig om en anställds intyg, så måste till exempel efter dennes uppsägning intyget anses ogiltigt. Om den privata nyckeln för certifikatet av någon anledning har blivit offentlig, måste den också läggas till i listan över ogiltiga certifikat (CRL). Du kan använda kommandot openssl ca för att hantera CRL .
Skapande av CRL:er:
openssl ca -gencrl -out crl.pemAtt lägga till onödiga certifikat görs med kommandot:
openssl ca -revoke bad_cert.pemEfter varje applicering av återkallelse är det nödvändigt att uppdatera CRL med kommandot
openssl ca -gencrlMer information kan hittas i manualen med kommandot man pkcs12 i Linux- terminalen, eller länken pkcs12(1) .
Det här avsnittet är baserat på LirJSSE, en Secure Sockets GOST Algorithm Support Extension for Java . För mer information om hur PKCS#12 implementeras i JSSE- biblioteket, se källan.
SunJSSE- leverantören tillhandahåller en komplett implementering av PKCS#12-formatet java.security.KeyStore för att läsa och skriva pkcs12-filer. Det här formatet stöds också av andra verktyg och applikationer för att importera och exportera nycklar och certifikat, som Netscape / Mozilla , Microsoft Internet Explorer och OpenSSL . Till exempel kan dessa implementeringar exportera klientcertifikat och nycklar till en fil med filtillägget ".p12".
Med LirJSSE- leverantören kan du få PKCS#12-nycklar via KeyStore API med butikstypen "pkcs12". Dessutom kan du se listan över installerade nycklar och motsvarande certifikat med kommandot keytool med alternativet -storetype inställt på pkcs12.
För säkerhets skull måste du komma ihåg att i Java 6 JDK finns samma PKCS#12-lagringsstödklasser inte bara i JSSE utan också separat i paketet sun.security.pkcs12 .
PKCS#12-lagringsimplementeringen i LirJSSE stöder dessutom GOST-algoritmer. Följande beskriver funktionerna i denna implementering.
När förvaret är laddat kontrolleras dess sammanfattningsintegritet , varefter alla certifikatkedjor dekrypteras. Den hemliga nyckeln dekrypteras endast på begäran med ett specifikt alias, men förblir i det krypterade tillståndet i det offentliga minnet. Kryptering av alla certifikatkedjor och beräkning av lagringssammandrag utförs endast när lagringen är sparad i en fil.
Certifikatkedjor associeras med privata nycklar i butiken av lokala identifierare. Den lokala identifieraren är en UTF-8- byte-array som bildas genom att lägga till en ny nyckel från strängen "Time" följt av en textuell representation av datumet och tiden då elementet lades till. När en ny nyckel läggs till anges också alltid motsvarande certifikatkedja och lösenord.
Den nya hemliga nyckeln kan skickas in för att läggas till valvet i klar form, eller redan krypterad. I det senare fallet anges inte nyckellösenordet.
Valvet kan inte innehålla både GOST- och icke- GOST- nycklar samtidigt . Motsvarande interna lagringstyp ställs in antingen när den laddas eller när den första nyckeln läggs till. Om lagringsutrymmet är tomt, är dess typ inte definierad i denna mening.
Ett alias för ett nyckelelement är i allmänhet valfritt. Om det finns ett element utan ett alias i arkivet, tilldelas aliaset det med tvång i form av ett internt serienummer. Faktum är att LirJSSE , precis som Sun JSSE , arbetar med lagringselement endast genom alias.
När du skapar lagringselement av olika program kan den interna strukturen för lagring av krypterade element skilja sig något. På grund av detta kan till exempel samma kedja av certifikat packas i en lagringsfil med hjälp av LirSSL och LirJSSE i strukturer av olika storlekar. Standarden tillåter detta, och det påverkar inte förvarets funktionalitet.
När du arbetar med JSSE , glöm inte att nyckelelementlösenord måste matcha lagringslösenordet. Standarden PKCS#12 tillåter i allmänhet flera lösenord i samma butik, men SunJSSE och LirJSSE stöder inte denna funktion.
Enligt överenskommelse med Top Cross-företaget konverteras lösenordet för hela lagringen i LirJSSE- programmet till UTF-16- format före användning (de sista två byten är noll). Och individuella lagringselement skyddas av samma lösenord, men i UTF-8- format .
LirJSSE - Secure Sockets Extension with GOST Algorithms for Java ger en jämförande beskrivning av den interna strukturen för PKCS#12-lagringsfiler i ASN.1 -format för RSA- och GOST- varianterna .