Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Tomorrow will take us away,
Far from home,
No one will ever
know our names,
But the bards' songs
will remain.
/Blind Guardian:
The bards' song/
2012. december 26.  
 * Office biztonság 
   
Az elmúlt néhány hétben (2012. november 19. - 2012. december 7.) részt vettem az ETSI (European Telecommunications Standards Institute) nemzetközi szabványosító szervezet egységes dokumentumformátumának biztonsági rétegéhez kapcsolódó interoperabilitási vizsgálatán (ETSI plugtest - ASiC signatures).

Mit jelent ez? Az "egységes dokumentumformátum" súlyos állításnak tűnik, azonban az elmúlt 4-6 év fejleményei alapján elég valószínű, hogy a "ZIP-csomagba zárt XML állományok" jó ideig meghatározzák az Office-okhoz kötődő formátumokat, illetve az ezeken túli világot is. A dokumentumformátumok történetével a Sűrített XML bejegyzésemben foglalkoztam. A "biztonsági réteg" alatt jelen esetben a sértetlenséget és hitelességet adó elektronikus aláírást értem, amelyre az ETSI az ETSI TS 102 918 szabványt hozta létre, ami az Associated Signature Containers (ASiC) formátumot takarja. A szabvány elsősorban az OCF (pl. Calibre .epub állományok), ODF (pl. Open/Libre Office .odt állományok) illetve UCF (pl. Adobe Navigator .nav állományok) formátumához igazodik. A Microsoft OOXML formátumát nem vizsgálja, de az alapfeltételek - XML, ZIP - adottak, azaz érdemes arra is figyelni. Az interoperabilitás mellett az ETSI szabvány bővítette is a lehetőségek körét, hiszen az XML (XAdES) aláírás mellett támogatja a CAdES (CMS/PKCS#7-típusú, ASN.1 bináris) struktúrán, illetve egyszerű időbélyegen (TST, Time-stamp token) alapuló megoldásokat is. Bevezetett ugyanakkor egy csoportosítást is, ami azt mutatja meg, hogy az összes (vagy legalábbis több) ZIP-ben tárolt állomány van-e lefedve egy vagy több aláírással (ASiC-E, azaz "extended") vagy az aláírás csak pontosan egy objektumra vonatkozik (ASiC-S, azaz "simple").

Mi volt a célom? Olyan elektronikus aláírás struktúrákat akartam létrehozni, amelyek megfelelnek az összes alábbi követelménynek:
  • XAdES (ETSI TS 101 903): A különböző Office termékek által alkalmazott XMLDSIG (IETF RFC 3275) nem felel meg az Európai Unió - illetve az aláírás teljes életciklusára vonatkozó működési logika - követelményeinek, hiszen sem időbélyeg, sem visszavonási adatok nem képezik részét. Banki analógiával élve ez olyan, mintha ATM-es pénzfelvételkor nem kerülne ellenőrzésre, hogy az adott bankkártya lopott-e, felfüggesztésre került-e. Az ETSI pontosan ezeket a hiányosságokat orvosolandó adta ki a XAdES szabványt.
  • ASiC (ETSI TS 102 918): A ZIP-csomagba zárt XML állományokban elhelyezhető elektronikus aláírások szabályait tartalmazza.
  • Open/Libre Office: A szabványokon túllépve kíváncsi voltam, hogy sikerül-e a való életben is bemutatni a működést, azaz lehet-e az ASiC által lefedett ODF formátumban létrehozni elektronikus aláírást úgy, hogy azt egy Open/Libre Office felismerje és elfogadja jónak. Mivel a PDF állományokba ágyazott elektronikus aláírások pontosan azért lettek népszerűek, mert Adobe Acrobat Reader minden gépen található, az Office alkalmazások révén ez a jó tulajdonság szintén adott lehetne. Fontos előnye azonban az Office-oknak, hogy míg egy PDF automatikus, tömeges feldolgozása, parse-olása bonyolultabb feladat, addig a ZIP konténer kicsomagolása könnyű, az XML feldolgozása pedig végső esetben akár string-ként értelmezve is elvégezhető. A PDF tehát inkább G2C/B2C/C2C kommunikációra lehet jó, azonban amikor pl. a közigazgatás a befogadó fél, akkor az XML-alapú dokumentumformátum előnyösebb lehet.





Mit értem el? A tervet végül sikerült teljesíteni! A szabványokat leíró XML sémáknak való megfelelés mellett kellett úgy módosítani az XML struktúrákon, hogy az megfeleljen az Open/Libre Office kívánalmainak is. Ennek érdekében azonban súlyosabb peremfeltételeknek is meg kellett felelnem:
  • Jelenleg az Open/Libre Office az SHA-1 lenyomatképző algoritmust és az azon alapuló elektronikus aláírást (sha1WithRSAEncryption) támogatja csak. Az SHA-256 lenyomatok és aláírások (sha256WithRSAEncryption) esetében hibát jelez. Bár, az SHA-1 algoritmusra teljes törés még nem ismert (erről bővebben ld. a P2P ütközések bejegyzésemet), 2012. január 1. óta már itthon is SHA-256 lenyomatokat alkalmazó tanúsítványokat lehet csak kibocsátani.
  • Az Open/Libre Office dokumentumai tartalmazhatnak 0 byte méretű állományokat is, amelyeket le kell fedni (lenyomatképzés), különben az ellenőrző funkció nem tud teljes bizonyossággal ítéletet mondani (a biztos az, ha minden állományt lefed az aláírás, nehogy pont egy érzékeny adatokat tartalmazó állomány kimaradjon). A probléma ezzel ott van, hogy külön, kőkemény követelmény vonatkozik arra, hogy 0 byte méretű állományokra ne lehessen lenyomatokat képeznie egy CEN CWA 14170 szabványnak ("Security Requirements for Signature Creation Applications") megfelelő alkalmazásnak...
  • A "mimetype" állomány tartalmazza a regisztrált MIME type értékét. Az Open/Libre Office számára ez azonban nem fontos, mert az állomány kiterjesztése (pl. .odt) alapján nyitja meg azt. A ZIP-csomagolásra azonban az ASiC szabvány tartalmaz követelményeket, amelyek bár egyszerűnek tűnnek, mégsem triviálisak: a "mimetype" állomány a ZIP-csomagolás során nem tömöríthető. Erre jelenleg egyik PHP library sem képes (a XAdES.PHP kapcsán ezeket kellett néznem), de a WinRAR ZIP-funkciója sem jó. Manuálisan, a WinZIP segítségével lehetett csak az előírtaknak megfelelő ASiC (itt: .odt) állományt létrehozni...
  • Voltak még más kevésbé fontos, illetve könnyen orvosolható feltételek is, amelyek már a szabvány hatókörén belüli finomításnak számítottak: a beégetett XML névterek (xmlns prefix), vagy az aláírás struktúrát tartalmazó állomány elnevezése, vagy a több, azonos dokumentumra vonatkozó aláírásnál kérdés volt, hogy egy vagy több állományba tárolja a kiszámított értékeket, vagy az ASiC-E kizárólagossága (azaz minden ZIP-csomagban levő állományt le kell fednie az aláírásnak). Ezekkel azonban már nem volt probléma...





Bár, hasonló kutatásokról nincs tudomásom, nagy eredménynek csak akkor fog ez számítani, ha a Microsoft Office OOXML állományainál is meglesz a "közös nevező". Sajnos, a Microsoft elég nyakatekert módon alkalmazta az elektronikus aláírásra vonatkozó szabványt, ezért itt több időt fog igényelni ezen "közös nevező" megtalálása...

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info