OpenPGP vagy S/MIME?

Az OpenPGP és S/MIME aláírási rendszerek tesztelését három levelezőkliensen végeztem: A Gmail webes felületén, az Outlook-on és a Kmail-en. A Kmail mindent minden formában támogat, toronymagasan kiemelkedik a mezőnyből. Az Outlook csak az S/MIME rendszerrel kompatibilis, abból is csak a Kmail által támogatott kétféle aláírási módszer egyikét támogatja aktívan, de a másikat is értelmezni tudja, viszont a MIME szerkezet menet közbeni módosulásaival (pl. levlista lábléc hozzáadása) nem sok értelmes dolgot tud kezdeni. A Gmail webes felülete egyik rendszert sem ismeri, a legjobb esetben is ismeretlen típusú csatolt fájlként jeleníti meg a digitális aláírások minden fajtáját, mint az Outook az OpenPGP-t. Mivel az Outlook csak az S/MIME-t támogatja, és elvileg Windows alapú vállalati rendszert akarunk építeni, valamint legjobb tudomásom szerint a magyar jog is csak bizonyos jogi és technikai feltételeknek megfelelő X.509 tanúsítványokra épülő S/MIME aláírásokat fogad el bizonyító erejűnek, ezért nyilvánvalóan az S/MIME felé kell orientálódnunk.

Ennek ellenére azért az OpenPGP-t is górcső alá vettem. A két digitális aláírási rendszer között sok hasonlóság van. Nyilván mindkettő hash kivonatot készít a levélről, majd ezt a felhasználó titkos kulcsával titkosítja. A nyilvános kulcsok tanúsítványokból nyerhetők ki. Az S/MIME X.509 tanúsítványokat használ, az ott megszokott PKI infrastruktúrára alapozva. Az OpenPGP saját tanúsítványszabvánnyal rendelkezik, a tanúsítványai egy teljesen nyilvános világszintű felhőben tárolódnak, és közösségi alapon bárki aláírhatja őket. Erre épül az ún. web of trust megbízhatóságvizsgálat. Mindkét szabvány csak a levél törzsét írja alá, bár legalább az egyik esetében (S/MIME) folynak már fejlesztések olyan irányban, hogy bizonyos fejlécmezőket átmásoljanak a levél törzsébe és ott aláírják őket, de a gyakorlatban nem láttam ennek semmi eredményét. Szövegszerkesztővel átírtam néhány OpenPGP és S/MIME módon aláírt levél from, to és subject fejlécmezőjét, de mind a Kmail mind az Outlook ezután is szemrebbenés nélkül érvényesnek találta az aláírásokat. A levéltörzs módosítására már természetesen mindketten felkapták a fejüket.

A kmail kétféle OpenPGP aláírást támogat:

1.: A régebbi, az ún. inline OpenPGP használata már nem javasolt: Nem a MIME szabványon alapul, hanem saját üzenetformátummal dolgozik. A legtöbb általam kipróbált levelezőkliens még csak megjeleníteni sem tudja rendesen, nem hogy ellenőrizni a hitelességét.

2.: Az OpenPGP/MIME módszer esetében a levél törzse szabványos MIME, az aláírás csatolt fájlként van jelen.

S/MIME aláírásból szintén kétfélét támogat a kmail:

1.: Az OpenPGP/MIME-hoz teljesen hasonló az S/MIME aláírás, de persze a saját kriptográfiájával.

2.: Az S/MIME-nak van egy ún. opaque (nem transzparens?) aláírási módszere is: Ebben az esetben az egész levétörzs egy kódolt csatolmányba van beágyazva.

Az általam vizsgált három levelezőprogram közül csak a Kmail képes mind a négy típusú aláírás létrehozására, mint ahogy az inline OpenPGP-t is csak ez jeleníti meg helyesen, de nem ellenőrzi rajta az aláírást, sőt ki sem írja, hogy alá van-e írva. A másik három aláírástípust tökéletesen kezeli mind küldőként, mind fogadóként, és rendkívül esztétikusan, informatívan jelzi, hogy a levél megbízható-e, ha igen, miért, stb.

Az Outlook csak az S/MIME szabványt ismeri, és ebből opaque típusút is tud értelmezni, de írni nem. Az OpenPGP-t ismeretlen típusú csatolásként vagy - az inline OpenPGP esetében - zagyva kódként jeleníti meg.

A Gmail webes felülete mindkét fajta aláírással ellátott levelet ismeretlen típusú csatolással ellátott levélként vagy zagyva kódként jeleníti meg. Az aláírási infrastruktúra webmail-be ágyazása nem számít biztonságosnak, mert ehhez a szolgáltató rendszerébe kellene feltölteni a titkos kulcsot, és a fentiek értelmében egyébként sem számítana end-to-end kriptográfiának. Vannak olyan böngésző-kiegészítők (browser pluginok), amelyek bizonyos általuk ismert/támogatott webmail rendszerek (pl. gmail, google apps for business, horde, stb.) JavaScript kódját módosítva/kibővítve lehetővé teszik a weben keresztül end-to-end digitális aláírást, de ezek használatát nem tekintettem komoly alternatívának az alábbi okok miatt:

-Nem megbízhatónak tűnő fejlesztők (Mi van, ha a plugin ellopja a titkos kulcsomat, és elküldi a fejlesztőjének, aki ebből hasznot húz?)
-Félkész állapotra utaló verziószámok.
-A böngészők és webmail rendszerek fejlődést nem mindig naprakészen követő kód.
-Rossz felhasználói élmény.

Miután mindezeket megvizsgáltam, eldöntöttem, hogy az S/MIME szabvány a befutó, minden valószínűség szerint Outlook használatával.

Tettem egyébként még egy érdekes kísérletet: Mi történik, ha a digitálisan aláírt levelet átküldöm egy levlistán (konkrétan mailman-en), ami módosítja a levél törzsét. Azt találtam, hogy a mailman nem nyúl bele a MIME törzs egyetlen összetevőjébe sem, hanem egy új MIME szakaszt fűz a levélhez, ebben van a levlista láblécének szövege. Ennek az az eredménye, hogy a levél lábléc feletti része továbbra is érvényesen alá van írva digitálisan. A kmail továbbra is esztétikus és informatív tájékoztatást nyújt arról, hogy a levél mely része megbízható, és melyik nem, az Outlook viszont megbicsaklik ezen a teszten.

SZERK 2014.12.11: Azt, hogy bizonyos S/MIME kulcspárok csak aláírásra vagy titkosításra használhatóak, a nyilvános kulcsot hordozó X.509 tanúsítvány keyUsage (esetleg extKeyUsage, basicConstraints) attribútuma határozza meg. Azaz a kulcspár technikailag bármilyen kriptográfiai feladatra alkalmas, de a szóban forgó attribútumok alapján a kriptográfiai szoftvernek meg kell tagadnia bizonyos feladatok végrehajtását. Az S/MIME esetében ezek az attribútumok nyújtanak támogatást ahhoz, hogy a felhasználónak külön kulcsa legyen az általa küldött levelek aláírására és a neki írt titkosított levelek dekódolására. A két kulcspárra pedig azért van szükség, mert az aláíró titkos kulcshoz SOHA SENKI más nem férhet hozzá, csak a kulcs tulajdonosa, a dekódoló titkos kulcsról viszont a felhasználó munkáltatója vagy más felettes szerve (pl. az állam) biztonsági másolatot készíthet egy jogilag és technikailag jól védett tárolóba (ún. key escrow), hogy ha a felhasználó esetleg meghalna vagy kilépne, akkor is olvashatóak maradjanak a neki írt titkosított levelek az arra illetékesek számára. Itt ugye az a probléma, hogy aki jogosult kinyerni a "zálogból" a dekódoló titkos kulcsot, az onnantól meg tudja hamisítani az adott felhasználó digitális aláírását, ez pedig ellentmond az ún. Non-repudiation követelménynek. Tehát: megfelelő bizalmassági szint eléréséhez külön kulcspár kell a levelek aláírásához, illetve a titkosított levelek fogadásához.