Rövid szöveges üzenetek titkosításának gyakorlati alkalmazási lehetősége és megvalósítási terve
1. A probléma
Adott egy kommunikációs csatorna, mely nyilvános, ezért ha bizalmas kommunikációt szeretnénk folytatni rajta, titkosítanunk kell. A forgalmazandó üzenetek hossza limitált, ezért a szokványos titkosítási eljárások használata korlátokba ütközik. Másrészt az információ, amit küldeni szeretnénk, szöveges, azaz nincs kihasználva a teljes rendelkezésünkre álló ABC.
A gyakorlatban:
A GSM rendszer Short Message Service szolgáltatásának segítségével maximum 140 byte-os csomagokban üzeneteket küldhetünk. A karakterek 7 bites ábrázolásával 160 karakternyi szöveges adat továbbítható egyszerre. A rövid szöveges üzenetek a GSM rendszerben a DCCH (Dedicated Control Channels) fizikai csatorna SDCCH (Stand alone Dedicated Control Channel) logikai csatornáján továbbítódnak, mely csatornán a kommunikáció titkosítatlan.
2. A titkosítás során fellépő nehézségek
Szöveges üzenet titkosításánál nem javasolt közvetlenül magát a szöveget elkódolni, mert a 7 vagy 8 biten ábrázolt latin ABC elemei nem, illetve nem egyenletes eloszlással használják ki a rendelkezésükre álló tartományt, ezáltal lehetőséget adva a titkosítás könnyebb visszafejtésére. Az üzenetet kódolás előtt tömörítenünk kell.
Rövid szöveges üzenet tömörítésénél előfordulhat, hogy a tömörített adat hosszabb lesz, mint az eredeti volt. Ennek oka lehet például az, ha a használt algoritmus kódtáblát igényel, melyet a tömörített adattal együtt kell forgalmaznunk, vagy ha például a szótárazó mechanizmus csak viszonylag nagyobb adatmennyiség esetén kezd hatékonyan működni.
Titkosításra az RSA algoritmust szeretném felhasználni. Itt a rövid üzenethossz a használható kulcsméretet fogja behatárolni, mert bár csomagokat összefűzve alkothatunk hosszabb üzeneteket, a rendszernek működőképesnek kell lennie a legrövidebb üzenetre is.
A gyakorlati megvalósításnál figyelembe kell vennünk, hogy a szöveg kódolását és dekódolását végző mobilkészülék, illetve SIM kártya limitált processzor illetve memóriakapacitással rendelkezik, illetve, hogy a kommunikációs csatorna drága, ezért törekedni kell a lehető legkisebb csomagszámra is.
3. A tömörítés problémája
A feladat a következő: adott egy maximum 160 karakteres szöveg, melyet a titkosítandó adat entrópiájának növelése céljából tömörítenünk kell, úgy, hogy a végeredmény (lehetőleg) ne legyen hosszabb, mint az eredeti adat volt. (Lehetőleg, mert ez teljes körűen nem tehető meg.) A feladat megoldására a Huffman-algoritmust választottam, egyrészt mert egyszerűen implementálható, másrészt, mert nagyon jó hatásfokkal tömörít szöveges üzeneteket.
A Huffman-algoritmus a szöveg tömörítéséhez egy bináris kódfát generál, melyen a fa levelei jelképezik az egyes jeleket, a levéhez vezető út pedig a jelhez rendelt kódot. Az algoritmus a kódfát a jelek előfordulási gyakorisága alapján generálja, azaz ezt az adatot ismertnek tekinti.
A tömörített adat csak a kódfa ismeretében dekódolható. A kódfa hossza 7 bites ABC-t és 16 bites maximális kódolt jelhosszt feltételezve: 128*16=2048 bit, 256 byte hosszú. Látható, hogy 140 byte adat tömörítéséhez további 256 byte információt mellékelve nem kapunk használható megoldást.
A kódfa továbbításának szükségességét két úton kerülhetjük ki.
1. Adaptív Huffman-algoritmus használata
Ebben az esetben nem olvassuk el a tömörítendő adatot kétszer, nem végezzük el a jelek elfordulási gyakoriságának számlálását, így nem tudunk előre kódfát építeni. Minden jelhez egy átlagos valószínűséget rendelünk (1-et vagy 0-át), és minden egyes jel elolvasása után a módosított előfordulási adatok alapján újraépítjük a kódfát. Ez a megoldás meglehetősen lassú, ám jó hatásfokú tömörítést ígér.
2. Rögzített kódfa használata
Valamely, a küldendő adatok szempontjából referenciának tekinthető, vagy egy teljesen önkényesen választott nagyméretű szöveg alapján generálunk egy kódfát, majd ezt mind a küldő, mind a fogadó oldalon rögzítjük. Ezzel elkerüljük a folytonos kódfa-építést, viszont a tömörítés hatékonysága meglehetősen nagy szórást mutathat a referencia-szöveg választásától, illetve a konkrét tömörítendő szövegtől függően.
3. A két módszer kombinálása
Referenciaszöveg alapján készítünk egy referencia-kódfát, melyet letárolunk mindkét oldalon, majd a tömörítés során minden 5. vagy 10. karakter elolvasása után az előfordulási adatokat helyesbítjük a konkrét szöveg adataival. Ennek a módszernek a hatékonyságához a referencia-kódfa előfordulási táblázatát oly módon kell normálni, hogy a benne levő szumma jelelőfordulás 80 körül alakuljon. Így 160 karaktert feltételezve a kódfa viszonylag gyorsan képes lesz alkalmazkodni a konkrét szöveghez.
|
|
Tömörítési
hatékonyság |
Szükséges
processzorkapacitás |
|
Normál Huffman mellékelt
kódtáblával |
5 (1)* |
Átlagos |
|
Adaptív Huffman |
4 |
Nagy |
|
Rögzített kódfa használata |
2 |
Kicsi |
|
Adaptív Huffman rögzített
kódfával |
3 |
Átlagos |
* Rövid tömörítendő üzenet mellett a továbbítandó táblázat mérete miatt
4. A titkosítás problémája
A titkosítást a címzett RSA nyilvános kulcsával fogjuk végezni, úgy, hogy előbb a küldendő adatot, mely kezdetben normál szöveg, becsomagoljuk. A kiválasztott tömörítő algoritmus használata után előáll a 139 byte titkosítandó adat. Az üzenet begépelése után a program először megkísérli 139 byte-os csomagokká tömöríteni a szöveget, a Huffman kódolás adaptív változatának rögzített kódfával kombinált verziójával. Amennyiben az eredmény nem kielégítő, azaz az első 139 byte tömörített eredménye hosszabb, mint az eredeti, akkor a tiszta adaptív verziót fogja használni, bármilyen eredményre vezessen is ez a tömörítés. Amennyiben a tömörített információ kevesebb, mint 139 byte, a maradék byte-okat véletlenszerű értékekkel töltjük fel, így fokozva a titkosítandó adat entrópiáját. A 140 byte-ból fennmaradó 1 byte adminisztratív információk részére van fenntartva.
Megoldandó probléma a küldő és fogadó oldalon egyaránt a kulcsok tárolása, és a titkosítás végrehajtása.
Erre a célra a WAP specifikációban ismertetett Wireless Identity Modult (WIM) használja fel a rendszer. A WIM tipikusan SmartCard-ként kerül megvalósításra, sőt, lehetőség van a mobilkészülékben már egyébként is jelen levő SIM kártyával való integrálására: SIM-WIM, SWIM. Ezzel egy bizalmas eszközt kapunk, ahol nagy biztonsággal tárolhatjuk kulcsainkat, illetve a rendszer másik kritikus elemét, a titkosításért felelős programot.
Az SWIM kártya rendelkezik kriptográfiai processzorral, képes végrehajtani az RSA algoritmust, jó minőségű véletlenszám-generátorral rendelkezik, illetve SHA-1 hash értéket tud készíteni. Amennyiben a kártyát felruházzuk JavaCard képességekkel is, akkor rendelkezésünkre áll egy olyan eszköz, mely programozható illetve bizalmas.
5. A felépíthető rendszer
A fentebb ismertetett algoritmusok és eszközök felhasználásával egy, a Nyilvános Kulcsú Titkosítási Rendszerhez (PKI) hasonló, szűkített megoldás készíthető, melynek a következő elemei vannak:
1. Kliens oldal
ˇ Kombinált SIM-WIM (SWIM) a kulcsok, illetve felhasználói tanúsítványok tárolására
ˇ Kódolást és dekódolást végző kód
2. Szerver oldal
ˇ Titkosított üzenetek továbbításáért felelős dedikált SMSC (Short Message Service Center)
ˇ Felhasználói tanúsítványok kezeléséért és továbbításáért felelős adatbázis
A rendszer felhasználói személyre szóló SWIM kártyát használnak mobilkészülékükben, mely tárolja titkos kulcsukat, illetve a szűkösen rendelkezésre álló memória miatt az 5-10 legsűrűbben használt partner felhasználói tanúsítványát, illetve +1-et az aktuálisan letöltendő tanúsítvány számára. Szerepel még rajta a tanúsítványokat tároló adatbázis nyilvános kulcsa, a tanúsítvány hitelességének ellenőrzéséhez. Ez a kártya tárolja a kódolásért, illetve a dekódolásért felelős programot is. JavaCard kártya esetén speciális típusú SMS (Point-to-point data download, 63-as típusú) fogadása eseményt vált ki, mely kezelésére programot írva megoldható a titkosított üzenet fogadása, a küldő azonosítása után a megfelelő tanúsítvány használata, illetve ha nem áll rendelkezésre, lekérése a központi adatbázisból.
A szolgáltatás elindításához a GSM operátor oldalán fel kell állítani egy, csak erre a célra dedikált SMSC-t, hogy a több darabra vágott üzenetek is a lehető legrövidebb időn belül kézbesítésre kerülhessenek, illetve a felhasználói tanúsítványok tárolásához szükséges központi adatbázist.
Egy üzenetküldés tipikus lefolyása:
1. Üzenet begépelése
2. Címzett kiválasztása
3. Címzett tanúsítványának megszerzése: SMS-ben, ha nincs rögzítve a kártya memóriájában
4. Üzenet tömörítése 139 byte-os csomagokká
5. Véletlen byte-ok előállítása a 139 byte eléréséhez, ha szükséges: ha a csomag nem tölti ki a 139 byte-ot (ez az egyetlen, vagy utolsó csomag)
6. 139 byte-os csomagok titkosítása a címzett nyilvános kulcsával
7. 1 byte-os header előállítása, mely tartalmazza, hogy hány csomag van összesen (0-2 bit), ez hányadik csomag (3-5 bit), melyik algoritmussal lett tömörítve a szöveg (6-7 bit)
8. 20 byte-os hash készítése SHA-1 algoritmussal a teljes szövegből, majd ennek titkosítása a küldő titkos kulcsával. (Szignatúra)
9. Titkosított üzenet küldése dedikált SMSC-n keresztül. (Az üzenetet tartalmazó csomagok + a szignatúrát tartalmazó utolsó csomag.)
10. Titkosított üzenet vétele és rögzítése a JavaCard applet segítségével
11. Küldő azonosítása az SMS-ben rögzített telefonszám segítségével: elvileg hamisítható a feladó, de a tanúsítvány lekérése utáni ellenőrzésnél ez kiderül. Adatterület takarítható meg ezzel.
12. Küldő tanúsítványának megszerzése
13. Üzenet dekódolása a fogadó titkos kulcsával
14. Üzenet kitömörítése, szignatúra ellenőrzése a küldő tanúsítványában szereplő nyilvános kulcs alapján
15. Üzenet megjelenítése, ha minden rendben
6. Összefoglaló
Látható, hogy a probléma megoldáshoz szükséges eszközök nagyrészt adottak, az rendszer ismert és kipróbált algoritmusok használatával felépíthető, a szükséges programok kifejleszthetők. A rendszer jelenleg csak elméletben vizsgálható, azt, hogy valóban megállná-e a helyét, csak egy pilot üzembe állítása után tudjuk eldönteni.
7. Irodalomjegyzék
4 Rop Gonggrijp, Ruediger Weis, Barry Wels SEMS Secure SMS Protocol, http://www.nah6.nl
4 Ericsson GSM System Survey. EN/LZT 123 3321
4 WAP-198, Wireless Identity Module Specification (http://www.openmobilealliance.org/)
4 Sike Sándor: Programozási módszertan II: Algoritmusok