Tételezzük fel, hogy tudunk publikus és privát kulcspárt generálni, mondhatnánk, hogy most már készen állunk a titkosított kommunikációra. Ezzel szemben azonban egy újabb problémával szembesülünk, mégpedig a kulcs tárolásának és a továbbításának problémájával.
De milyen problémáról is beszélünk valójában? Az adatok kódolásához köthető problémáról, illetve problémákról. Az 1970-es években, amikor megjelentek az aszimmetrikus rendszerek, a 8 bit = 1 byte szabály sem volt tekinthető kőbevésettnek. Voltak (és a mai napig is vannak még) olyan számítógépek amelyek 6, 7 vagy éppen 9 vagy 12 bitet tekintenek egy byte-nak. A ma ismert 8 bites byte-ot csak 1993-ban szabványosították az ISO/IEC 2382-1 alatt.
Az, hogy hány bit egy byte, addig nem számít, amíg csak egy géppel dolgozunk, de ha hálózati átvitellel dolgozunk, vagy át kell vinnünk adatot, akkor nagyon nem mindegy, hogy a célgép esetén hány bit számít egy byte-nak, mert elcsúszás és hiba keletkezik a kommunikációban. Ez pedig titkosítás esetén részleges adatvesztést vagy rosszabb esetben teljes adatvesztést eredményezhet.
Ha ez nem lenne elég probléma, még ott van az endianness, avagy a byte sorrend kérdése. A processzorok esetén fontos tényező a bitszám. Ez két dolgot határoz meg: a kezelhető memória méretét és az egyszerre feldolgozható bitek számát. Ezt szokás szóméretnek is nevezni. Egy 64 bites processzor 64 bites vagy 8 byte-os szavakkal dolgozik, vagyis egy utasítás is legalább ilyen hosszú.
Azonban ez a 8 byte két módon is értelmezhető: big-endian módon és little-endian módon. Ezt egy példán keresztül lehet jól bemutatni. Legyen adott a 1 245 391 901 szám, amit reprezentálni szeretnénk binárisan. Ez hexadecimálisan kifejezve a 4A 3B 2C 1D byteokat eredményezi. Ebben a big-endian felírásban a legnagyobb helyiértékű bájt a 4A. Egy little-endian rendszeren azonban a korrekt byte-sorrend pont a fordítottja: 1D 2C 3B 4A, vagyis itt a legkisebb helyiértékű byte szerepel a legnagyobb memóriacímen.
Ez a sorrend számítógép architektúránként változó, de a leggyakoribb az x64 és a x86 architektúráknak köszönhetően a little-endian tárolás, amit anno azért választott az Intel, mert lényegesen egyszerűbb matematikai műveleteket végezni és processzort építeni erre a sémára. Egyes processzorok esetén a sorrend konfigurálható. Egy ARM processzor tud little-endian és big-endian módon is működni.
DER és PEM
Ennyi felvezetőből talán látható, hogy ha hálózati átvitelről beszélünk, akkor a küldő rendszernek meglepően sokat kellene tudnia a fogadó oldalról, hogy ne legyen probléma az átvitel során. Éppen ezért a hálózati átvitelre különböző szabványokat hoztak létre, így a küldőnek csak a hálózati szabványt kell beszélnie anélkül, hogy tudna a fogadóról bármit is.
Az egyik ilyen szabvány az Abstract Syntax Notation One (ASN.1) és a hozzákapcsolódó X.690, amit 1984-ben szabványosítottak. Az X.690 lényegében egy bináris szerializációs formátum, ami egy olyan bináris formátumot definiál, amely az ezt implementálók között lehetővé teszi adatstruktúrák átvitelét és feldolgozását.
Ez két kódolási módszert definiál. Egy szabadosabb BER (Basic Encoding Rules) specifikációt és egy leginkább kompatibilitásra maximalizált DER (Distinguished Encoding Rules) sémát.
Mivel ez az egyik legősibb formátum RSA és elliptikus görbe kulcsokkal is találkozhatunk ilyen formátumban. Ezek általában .cer, .crt vagy .der kiterjesztéssel rendelkeznek.
Mivel a DER egy bináris formátum, nem igen alkalmas HTTP feletti vagy E-mail továbbításra, amelyek leginkább szöveg alapúak. Ebből adódóan született meg a PEM (Privacy-Enhanced Mail) de facto formátum, ami a DER kódolt kulcsot base64 segítségével kódolja. Általában az ilyen fájloknak .pem kiterjesztése van. Szövegesen egy BEGIN és END blokkról lehet őket felismerni, ami a privát kulcs esetén így néz ki:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
XML
A kulcs adat XML formátumban is tárolható. Mivel az RSA és a XML is a .NET 1.0-ás (2002) kiadásában is megtalálható, kézenfekvő volt a Microsoft számára, hogy XML-ben lehetőségünk legyen tárolni a kulcsokat. Azonban az ő megoldásuk megelőzte a W3C által később elfogadott XML struktúrát, amit az XML Key Management Specification alatt szabványosítottak.
Az egyetlen különbség a Microsoft és a W3C XML dokumentumai között a root tag. A Microsoft a XML kulcsok esetén a RSAKeyValue tag-et használja, míg a W3C szabványban definiált XML1 RSAKeyPair tag-et használ. A root tag nevének eltérésén kívül nincs különbség a két formátum között.
X.509
Az X.509-es szabvány a HTTPS/SSL és TLS kommunikációban használatos tanúsítványok formátumát definiálja. A kétkulcsos rendszerek esetén említettem, hogy önmagában az, hogy Alice és Bob rendelkezik egy kulcspárral, még nem teszi biztonságossá a kommunikációt, mivel, ha Alice csak Bob publikus kulcsával rendelkezik, akkor valójában nincs elég információ birtokában, hogy valóban Bob-al kommunikál.
Éppen ezért az aláírás és hitelesítés mechanizmusára kidolgozásra került az X.509-es szabvány, amely digitális aláírás segítségével igazolja Alice számára, hogy valóban Bob-al kommunikál. Ez az igazolás úgy történik, hogy Bob hitelesíti magát egy 3. félnél, aki a digitális aláírásával hitelesíti, hogy a publikus kulcs valóban Bob-hoz tartozik. Ez a 3. fél lesz a Certification Authority, röviden CA vagy magyarul Tanúsító Hatóság.
Ilyen Tanúsító Hatóságból több is van és a böngészőkben és egyéb publikus kulcsú infrastruktúrát alkalmazó szoftverekben megtalálhatóak a digitális aláírásaik, hogy a szoftverek ellenőrizni tudják a CA-k által kibocsájtott tanúsítványok eredetiségét.
Ha Bob nem rendelkezik egy olyan tanúsítvánnyal, ami rendelkezik egy CA aláírásával, akkor nem lehetünk benne biztosak, hogy valóban ő van a vonal másik végén. Ha pedig saját maga írja alá a tanúsítványát, mint egy CA, akkor úgynevezett Self Signed tanúsítvánnyal dolgozik, ami szintén nem ad okot bizalomra. A Self Signed tanúsítványok leginkább a 2010 előtt voltak jellemzőek intranetes és belső oldalakon, mivel egy CA által hitelesített tanúsítvány a hitelesítés mértékétől függően és a CA státuszától, rangjától függően akár egy kisebb vagyonba is kerülhet még ma is.
Éppen ezért 2014-ben az EFF (Electronic Frontier Foundation) a Mozilla és később más csatlakozó tagok létrehozták a Let’s Encrypt CA-t, ami nonprofit elven működik. Ennek segítségével bármelyik domain tulajdonos igényelhet magának olyan tanúsítványt, amit a böngészők és a legtöbb SSL/TLS kommunikációt támogató program elfogad.
Az X.509 tanúsítványok formátum ügyileg a korábban említett DER és PEM kódolással is rendelkezhetnek, illetve Windows esetén találkozni még a PFX formátummal (.pfx kiterjesztés) is. Ez PKCS#12 kódolással tárolja a tanúsítványokat.
X.509-es tanúsítvány tárolható még .p12 kiterjesztéssel is, ami szintén PKCS#12 kódolást használ és lényegében a PFX formátum utódjának tekinthető. A .pfx és .p12 azonban sokáig nagy népszerűségnek nem örvendett, mivel az ilyen fájlok írása és olvasása nagyságrendekkel komplikáltabb, mint a DER és PEM formátumok.
.NET alatt a kód aláírására szintén .pfx formátumú X.509 tanúsítványokat használhatunk, illetve Java esetén a 9-es verzió óta szintén a .pfx formátum a kulcstárolás alapértelmezett módszere.