TFTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren

Átírás

1 Pázmány Péter Katolikus Egyetem TFTP szerver megvalósítása Texas Instruments Stellaris LM3S6965 mikrokontrolleren Diplomaterv SZERZŐ: Kopcsó Tamás KONZULENS: Tihanyi Attila Információs Technológiai Kar Budapest, május 15.

2 Hallgatói nyilatkozat Alulírott Kopcsó Tamás, a Pázmány Péter Katolikus Egyetem Információs Technológiai Karának hallgatója kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, és a szakdolgozatban csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a Szakdolgozatot más szakon még nem nyújtottam be. Budapest, május 15. Kopcsó Tamás

3 Tartalomjegyzék 1 Bevezetés A kitűzött feladat A dolgozat szerkezete Beágyazott rendszerek a szakirodalom alapján Embedded processzorokat tartalmazó rendszerek felépítése, működése, programtárolók tartalmának módosítása [1] Flash memória programozás [2] Alkalmazásból történő programozás [2] Beágyazott rendszerek hálózati kommunikációja [3] Az UDP protokoll Kapcsolat létrehozás: IP cím: Port szám: Kliens-szerver alkalmazások: Adatkapcsolati réteg Ethernet, ARP: Az FTP és a TFTP protokoll összehasonlítása A File Transfer Protocol [8][9] A Trivial File Transfer Protocol [10] Összehasonlítás és választás Titkosítási eljárások áttekintése [12] Bevezetés Egyszer használatos bitminta, a XOR titkosítás Szimmetrikus kulcsú algoritmusok DES:... 34

4 4.3.2 AES: Döntés A hardver eszköz ismertetése ARM processzor Stellaris 32-bit ARM Cortex M széria Texas Instruments Stellaris EKC-LM3S6965 Evaluation Kit [14] /100 Ethernet vezérlő: Az lwip felhasználása, TFTP szerver megvalósítására Az lwip Felhasznált protokollok API [15] Adattípusok: Netbuf: Konklúzió A CooCox rendszer alkalmazása A CooCox rendszer A CoOS operációs rendszer [17] A CoOS tulajdonságai: A CoIDE fejlesztőkörnyezet [16] Debug Az lwip migrálása CoIDE fejlesztőkörnyezetre A migrálás folyamatának leírása Interruptok [18] TFTP szerver implementálása az alkalmazási rétegben A függvények ismertetése: Titkosító program implementálásának ismertetése Tesztelési módszer ismertetése, eredmények értékelése A TFTP szerver tesztelése... 61

5 11.2 A titkosító program tesztelése További lehetőségek Összefoglalás Köszönetnyilvánítás A rövidítések jegyzéke Az ábrák jegyzéke Irodalomjegyzék... 71

6 Kivonat A TCP/IP protokoll struktúra egyik legősibb, az alkalmazási rétegbe tartozó protokoll családját, az állományátvitelre szolgáló szabványok (FTP, TFTP) képezik. Feladatom egy beágyazott rendszer önálló programfrissítésének megoldása, számítógép hálózaton keresztül, a TFTP protokoll alkalmazásával. Ez a szabvány nem gondoskodik a hálózaton utazó állományok védelméről. Ezen hiányosság pótlására egy titkosítási eljárást implementáltam. A dolgozat keretében áttekintem a beágyazott rendszerek felépítését, működését és hálózati kommunikációval történő kiegészítésének módszereit, valamint az általam vizsgált titkosítási szabványokat, nemzetközi irodalom alapján. Röviden bemutatom a rendelkezésemre álló eszköztárat, mellyel dolgoztam. Az elkészült szoftverrendszer a Pázmány Péter Katolikus Egyetem Információs Technológiai Karán futó, Elektromos Izomstimulátor projekt részét képezi.

7 Abstract Standards for file transfer (FTP, TFTP) form one of the oldest protocol family in TCP/IP protocol suite belonging to the application layer. My task was to create the updating method of a program running on an embedded system via computer networks with TFTP protocol. This standard does not ensure the protection of the packets travelling on the network. In order to solve this deficiency I implemented an encryption procedure. In my thesis I review the construction and the operation of embedded systems and methods for implementing network communication in such systems, as well as the reviewed encryption standards, based on international literature. I present the tools at my disposal shortly. The complete software system is part of the Electrical Muscle Stimulator project of the Faculty of Information Technology at the Peter Pazmany Catholic University.

8 Abstrakte Die der Bestandsübertragung dienenden Normen (FTP, TFTP) bilden die älteste, in die Anwendungsschicht gehörende Protokollfamilie der TCP/IP Protokollstruktur. Meine Aufgabe war die Lösung der selbstständigen Programmaktualisierung eines eingebetteten Systems durch Computernetzwerk mit Anwendung des TFTP Protokolls. Diese Norm sorgt nicht für den Schutz des auf dem Netzwerk laufenden Bestandes. Um diesen Mangel zu kompensieren habe ich ein Schlüsselungsverfahren implementiert. Im Rahmen meiner Diplomarbeit überblicke ich den Aufbau, das Funktionieren und die Methoden der Ergänzung mit Hilfe der Netzkommunikation der eingebetteten Systeme, darüberhinaus die von mir untersuchten Verschlüsselungsnormen aufgrund internationaler Literatur. Kurz präsentiere ich die zur Verfügung stehende Symbolleiste womit ich gearbeitet habe. Das fertiggestellte Software-System bildet einen Teil des elektronischen Muskelstimulatorprojektes das an der Informatiek-Technischen Fakultät der Katholischen Universiteit Peter Pazmany läuft.

9 1 1 Bevezetés A dolgozatban egy beágyazott rendszer, számítógép hálózati kommunikációjának adatátviteli megoldásával, az átvitt adat védelmével és a beágyazott rendszert működtető szoftver, hálózaton keresztül történő frissítésével foglalkozom. Életünk egyre szélesebb területein alkalmazunk számítógép hálózatra, leggyakrabban az Internetre kötött, mikroprocesszor vezérelte berendezéseket. Ilyen eszközök előfordulnak a háztartásokban,(televízió, hűtőszekrény, riasztó berendezés), az egészségügyben (elektromos izomstimulátor, komputertomográf, MRI berendezés), a szállítmányozásban (navigációs eszközök) és egyre több ember zsebében, okos telefonok formájában. 1.1 A kitűzött feladat Munkám elsődleges célja, az Egyetemen futó, Elektromos Izomstimulátor projekt keretében, a készülő berendezés távoli programfrissítésének és konfigurációjának lehetővé tétele volt, Ethernet alapú hálózaton keresztül. Első feladatom a beágyazott rendszerek, ezen belül a felhasznált eszköz tanulmányozása, megismerése és használatának elsajátítása volt. Ismereteket kellett szereznem a lehetséges hálózati kommunikációs lehetőségekről. Meg kellett vizsgálnom, hogy milyen módon lehet egy beágyazott rendszert hálózatra kapcsolni és ezen keresztül kommunikációt létrehozni. A kiírás fontos részét képezte a titkosítási eljárások vizsgálata, a megismert módszerek közül a legalkalmasabb eljárás elkészítése és alkalmazása. Meg kellett terveznem a feladat megoldását megvalósító szoftverrendszert, mely az egyetem által rendelkezésemre bocsájtott mikrokontrolleren működni képes. A fejlesztéshez egy új, Eclipse alapú beágyazott fejlesztőkörnyezetet használtam, mely kapcsolódik az Egyetemen oktatott rendszerekhez és később oktatási célra használható. A tervek alapján elkészítettem a szoftverrendszert, melyet részletesen ismertettem és teszteltem. Végül a tesztelésről és a teszteredmények értékeléséről a dolgozat végén számoltam be.

10 2 1.2 A dolgozat szerkezete A dolgozat 2. fejezetében áttekintést adok a beágyazott rendszerek működéséről, és hálózati kommunikációjának lehetőségeiről. A 3. fejezetben két protokollt ismertetek és hasonlítok össze, melyek a TCP/IP architektúra alkalmazási rétegében, állomány átviteli feladatot képesek ellátni. A 4. fejezet részletes elemzést tartalmaz a munkám során megismert titkosítási eljárásokról. Az 5. fejezetben bemutatom a felhasznált hardver eszközt. A 6. fejezetben ismertetek egy TCP/IP protokollcsalád megvalósítást, és bemutatom, hogy miként használtam fel a feladatom megoldására. A 7. fejezetben röviden áttekintem az alkalmazott fejlesztőkörnyezetet, majd a 8. fejezetben bemutatom, hogy milyen úton jutottam el oda, hogy a munkát ezen keresztül végezhessem. A 9. és 10. fejezetben ismertetem a TFTP szervert és a titkosító programot, majd a 11. fejezetben ezek teszteléséről számolok be. A 12. fejezetben felvázolom a további lehetőségeket, amiken keresztül eredményeim még sokoldalúbbá tehetők.

11 3 2 Beágyazott rendszerek a szakirodalom alapján Az ARM Cortex processzorokat tartalmazó rendszerek működésének és működtetésének megértéséhez nemzetközi irodalmat tanulmányoztam. Ebben a fejezetben összefoglalom az ezzel kapcsolatos ismereteimet. 2.1 Embedded processzorokat tartalmazó rendszerek felépítése, működése, programtárolók tartalmának módosítása [1] A munkámhoz használt mikrokontroller, ARM technológián alapuló Cortex-M3 típusú processzor (2.1. ábra). A Cortex családnak három fő változata létezik. Az első az A profilú processzorokat tartalmazza, melyek esetében a fejlesztők a teljesítményre helyezték a hangsúly. A második profil az R széria, melyeket a valós idejű műveletek támogatására optimalizáltak. Végül a harmadik profil az M széria, mely költséghatékony, alacsony fogyasztást kínál, magas teljesítmény mellett, mikrokontrolleres alkalmazások futtatásához. A korábbi ARM7 processzorokkal ellentétben, a Cortex-M3 egy módosított Harvard architektúra, így több busz segítségével támogatja a párhuzamos műveletvégzést, ezzel gyorsítva a működést. Támogatja továbbá a sorban állás nélküli adathozzáférést, mely lehetővé teszi a belső SRAM memória hatékony kihasználását.

12 ábra: a Cortex-M3 processzor [1] A mikrokontroller egy sztenderdizált, 32 bites magot, BUS struktúrát, NVIC-et, debug rendszert és sztenderd elrendezésű memóriát tartalmaz (2.1. ábra). Az eszköz elektronikus, ezért fontos volt számomra, hogy megvizsgáljam az áramellátás kérdéskörét. Ezt a témakört az STM32 Cortex-M3 alapú mikrokontrolleren keresztül jártam körbe, mely áramellátása mindössze annyiban különbözik a használt mikrokontrollertől, hogy külső telepről is működtethető. Az STM32 működéséhez a V-os tartományban, feszültséget szolgáltató táp szükséges. Az így kapott feszültségből egy belső szabályozó 1.8V-ot állít elő a Cortex mag számára. Az STM32 ezen felül még két választható energiacsatlakozóval rendelkezik. Az egyik a valós idejű órajel generátorhoz a másik egy alacsony számú regiszter csoporthoz kapcsolódik, melyek telepről nyerhetik az energiát akkor, ha az STM32 alacsony fogyasztású állapotban van. Abban az esetben, az összeállítás nem tartalmaz telepet, a VBAT-ot a VDD-hez kell csatlakoztatni (2.2. ábra).

13 ábra: az STM32 tápellátása [1] A második opcionális áramforrás az ADC üzemeltetésére szolgál. Ha ez használatban van, a fő VDD feszültségforrás V lehet ábra: a szükséges külső kapacitások [1] Belső reset áramkörrel és belső feszültség szabályozóval mindössze hét külső kapacitásra van szüksége a processzornak (2.3. ábra). A mikrokontrollerek fontos része a reset áramkör, mely feladata, hogy a mikrovezérlőt egy előre meghatározott kezdeti állapotba hozza. A Cortex-M3 belső reset áramkört tartalmaz, ami addig reset állapotban tartja az eszközt, míg a VDD 2.0V alatt van, 40mV hiszterézissel (2.4. ábra).

14 ábra: a belső power on és power down reset gondoskodik a processzor reset állapotban tartásáról, amíg nincs stabil áramforrás [1] Szigorúan véve a külső reset áramkör nem része a Cortex-M3 magnak. Azonban a fejlesztés közben az nrst pin hozzákapcsolható egy egyszerű reset kapcsolóhoz. Az nrst a JTAG debug porthoz (2.5. ábra) is csatlakoztatható, így a fejlesztőeszköz ki tud kényszeríteni resetet a mikrokontrolleren. Az processzor számos belső reset forrással rendelkezik, melyek képesek felismerni a hibás működési körülményeket ábra: egyszerű hardver alaprajz JTAG csatlakozóval [1] A digitális processzorok egyik alapegysége az oszcillátor, mely az órajelet szolgáltatja a végrehajtásnak, ezzel meghatározza a működési frekvenciát és ezzel együtt részben a számítási sebességet. A Cortex-M3 belső RC oszcillátorokkal rendelkezik, melyek képesek a PLL számára órajelet biztosítani. Ez lehetővé teszi, hogy a mikrokontroller a maximális, 72MHz-es frekvencián

15 7 működjön. A belső oszcillátorok azonban nem olyan stabilak és megbízhatóak, mint a külső, kristály alapú, nagy sebességű társaik. A fő külső órajel forrás arra szolgál, hogy származtassa a Cortex processzor periférikus óráit. Ezt az órajel forrást nagy sebességű, külső oszcillátornak nevezzük (HSE Osc). Ez lehet kristály, kerámia rezonátor vagy egy a felhasználó által szolgáltatott forrás. Utóbbi esetben, ez lehet négyszög, szinusz vagy háromszög hullámforma, de az aktív állapotának 50%-nak kell lennie és maximum frekvencia pedig 25MHz kell, hogy legyen. Ha egy külső kristály vagy kerámia rezonátort használ, akkor ennek 4-16MHz-es tartományban kell működnie. Mivel a belső PLL felszorozza a HSE oszcillátor frekvenciáját egy egész számmal, a külső órajelnek a 72MHz tényezőjének kell lennie. Így a teljes működési frekvencia könnyedén származtatható. A Cortex-M3 egy második külső oszcillátorral is rendelkezik, amit alacsony sebességű, külső oszcillátornak hívunk (LSE OSc). Ez a valós idejű és a watchdog órajel forrására használható. Az LSE oszcillátor úgy, mint a HSE oszcillátor lehet külső kristály, vagy a felhasználó által szolgáltatott órajel forrás, a HSE oszcillátor esetében megadott paraméterekkel. Mindkét esetben az LSE oszcillátornak KHz-es frekvenciát kell adnia, ami képes biztosítani a valós idejű óra működését. A belső, alacsony sebességű oszcillátor támogatni tudja a valós idejű órát, de ez nem olyan pontos, így ha a tervezéskor szükség van az RTC használatára, akkor az LSE használata előnyösebb. Az oszcillátorok az órajel származtatásán kívül, időmérésre is használhatók. A GPIO pinek egyike konfigurálható úgy, hogy a mikrokontroller órájának kimenete legyen. Ebben az esetben az MCO pin a négy különböző órajel forrás egyikének kimenete lehet. Szót kell ejtenem a BOOT lehetőségekről, mivel feladatom megoldásához szükségem volt az ezekkel kapcsolatos ismeretekre. Az eszköz három féle boot módban indulhat el. Ezek két külső boot pin segítségével választhatók ki: BOOT0 és BOOT1. A boot mód megváltoztatásával a mikrokontroller másmás memória területekről fog indulni. Ez lehetővé teszi, hogy programot futtassunk a flashből, a belső SRAM-ból vagy a rendszermemóriából. Ha a rendszer memória kerül kiválasztásra, a Cortex-M3 egy gyárilag programozott bootloader-e indul el, mely lehetővé teszi a felhasználói flash újraprogramozását. Normál működés esetén a BOOT0-át a földhöz kell kötni. A többi boot módot jumperek megfelelő felhelyezésének segítségével lehet kiválasztani. Ez tipikusan a belső bootloader-rel történő, mezőfrissítés esetén szükséges. A bootloader használata esetén az USART1 az alapértelmezett interfész a PC-ről történő kódletöltéshez, így a rendszerhez illeszteni kell egy RS232 driver chip-et.

16 8 A programozó számára nagy segítséget nyújtanak a debug eszközök, melyek segítségével a hibakeresés meglehetősen nehéz feladata lényegesen egyszerűsödik. A Cortex processzor debug rendszere két féle csatlakozási sztenderdet támogat: az öt pines JTAG portot és a két pines Cortex soros portot. Mindkét változat esetében a GPIO pin áldozatul esik a debugger használatának. Reset után a Cortex CPU átkapcsolja ezeket az alternatív működési módjukba, így a debug port elérhetővé válik. Ha mégis szükség van a GPIO lábakra, akkor erről gondoskodni kell a program kódban a megfelelő regiszterek átállításával. Az 5 lábas JTAG interfész egy 20 lábas IDC típusú kapcsolóhoz van kivezetve, ami szabványos JTAG lábkiosztással rendelkezik. A soros interfész a Port A 13-at használja soros adatnak, a Port A 14 et pedig soros órának. Most röviden áttekintem a Cortex mikrokontroller architektúrát. A mikrokontroller egy Cortex-M3 processzor magra épül, mely dedikált utasítás buszon keresztül, a flash memóriához csatlakozik (2.6. ábra). A Cortex rendszer és adatbuszai az ARM AHB (Advanced High Speed Busses) mátrixához kapcsolódnak. A belső SRAM közvetlenül csatlakozik az AHB mátrixhoz, ahogy a DMA egység is. A perifériák két ARM APB (Advanced Peripherial Busses) buszon helyezkednek el, melyek az AHB mátrixhoz - ami azonos órajelen működik, mint a processzor - kapcsolódnak. Az APB2 a maximális, 72MHzen tud működni, de az APB1 csak ennek a felére képes. Mind a Cortex, mind pedig a DMA alkalmas busz master funkció betöltésére. A busz mátrix párhuzamossága miatt, csak akkor van szükség arbitrációra, ha mindkettő egyszerre kívánja elérni az SRAM-ot, az APB1-en vagy APB2-t ábra: a bus matrix [1] A processzor aritmetikai és logikai egysége nem működhetne memória nélkül. A Cortex-M3 processzorok memóriarendszerét az STM32 mikrokontroller segítségével szemléltetem. Habár az STM32 számos belső busszal rendelkezik, a programozónak 4Gbyte lineáris memóriateret biztosít. Mivel Cortex alapú mikrokontroller, így a memóriatérképnek a hagyományos Cortex elrendezést kell követnie. Így a program memória a 0x

17 9 címtől, a chipen lévő SRAM a 0x címtől, a felhasználói perifériák a 0x címtől és a Cortex regiszterek pedig a sztenderd címüktől, azaz a 0xE címtől indulnak ábra: a memória térkép [1] A flash memória régió három részre osztható. Az első a felhasználó számára rendelkezésre álló memóriaterület, a 0x címtől. A következő a rendszer memória, ami a flash memória 4Kbyte-os része, gyárilag a bootloader-rel felprogramozva. Az utolsó egység a 0x1FFFF800 címtől kezdődik és opció bájtok csoportját tartalmazza. Ezek segítségével rendszerbeállítások alkalmazhatók az STM32-n. A bootloader-t úgy tervezték, hogy az USART1-en keresztül tudjon programkódot letölteni, majd ezt a felhasználó flash memória részre felprogramozni. Ahhoz, hogy az STM32 bootloader módba kerüljön, a külső BOOT0 és BOOT1 pin-eket rendre alacsonyan illetve magasan kell tartani. Ekkor a rendszer memória blokk a 0x címen fog megjelenni. Reset után, az STM32 elkezdi végrehajtani a bootloader utasításait. A mikrokontrollerhez készített bootloader program segítségével, PC-ről lehet a felhasználói programot törölni majd beégetni. A teljesítményhangolás különösen nagy jelentőséggel bír a kis erőforrás igényű, korlátozott számítási kapacitással rendelkező rendszerek esetében. Meg kell tehát vizsgálni, hogy, hogy lehet maximalizálni ezt a tulajdonságot. A vizsgált mikrokontroller, a két külső oszcillátoron kívül két belső oszcillátort is tartalmaz (2.8. ábra). A nagy sebességű belső oszcillátor 8MHz-en, míg az alacsony sebességű khz-es frekvencián üzemel. Utóbbit a valós idejű órához és a watchdog-hoz tervezték.

18 ábra: az órajel fa két belső és két külső oszcillátorral [1] Az ábrán látható (2.8. ábra), hogy az mikrovezérlő összetett órajel fával rendelkezik. Két külső, két belső oszcillátort és egy PPL-t tartalmaz. A Cortex processzor órajelét mind a külső, mind a belső nagy sebességű oszcillátortól, mind pedig a PLL-től is nyerheti, melyet a külső és belső nagy sebességű oszcillátor is irányíthat. Így a processzor külső oszcillátor nélkül is képes 72MHz-es órajelen működni. A dolog árnyoldala, hogy a belső oszcillátor nem egy pontos, stabil 8MHz-es forrás. Ahhoz, hogy a sorosan kommunikáló perifériákat vagy pontos időzítést igénylő funkciókat megbízhatóan lehessen használni, az külső oszcillátor alkalmazása ajánlott. Az oszcillátorok, a PLL és a busz konfigurációjára szolgáló regiszterek is a reset és órajel irányító csoportba tartoznak (RCC). Reset után a processzor a HSI oszcillátor alapján megállapítja az órajelet. Miután ez megtörtént, a külső oszcillátor kikapcsol. Ezután bekapcsol a HSE oszcillátor mely kis idő elteltével stabilizálódik. A külső oszcillátort az RCC Control register-ben lehet bekapcsolni. A stabil működést egy készenléti bit jelzi. Amint stabil állapotba kerül, beállítható a PLL bemenetének. A PLL kimeneti frekvenciája egy egész szorzó érték kiválasztásával lehetséges, mely az RCC_PLL konfigurációs regiszterében tárolódik. Egy 8 MHz-es oszcillátor esetében, a PLL-nek 9-el kell szoroznia a kimeneti frekvenciát, hogy a maximum 72 MHz-es órajelet generálni tudja. Amint a PLL szorzó kiválasztása megtörtént, a PLL engedélyezhető a kontrol regiszterben. Amint stabilizálódik, a PLL ready bit bebillen és a PLL kimenete kiválasztható lesz, mint a Cortex processzor órajel forrása. Amint a PLL kiválasztásra kerül, mint rendszer órajel forrás, a Cortex processzor a maximális, 72 MHz-es sebességen kezd üzemelni. Annak érdekében, hogy a chip maradék része is az optimális sebességen tudjon működni, az AHB és APB buszokat konfigurálni kell a hozzájuk tartozó regisztereken keresztül.

19 11 A felhasználói programokat többek között a flash memóriában lehet tárolni, mely használatát a flash puffer gyorsítja és egyszerűsíti. A mikrokontroller felépítését vizsgálva észrevehető, hogy a Cortex-M3 mag a belső flash tárolóhoz egy dedikált I-BUS-on keresztül csatlakozik, mely a CPU-val azonos frekvencián üzemel, azaz amint a PLL aktiválódik, a mag 72MHz-es sebességen kezd működni. Mivel a Cortex processzor alapvetően egy egyciklusos gép, 1.3ns-onként megpróbál csatlakozni a flash memóriához. Az rendszer felállásakor a belső, 8MHz-es oszcillátorról működik, így az elérési idővel nincs probléma. Azonban, amint a PLL aktiválódik - így az órajel forrásává válik - a flash elérési ideje túl hosszú lesz (35 ns), hogy lehetővé tegye a Cortex processzornak, hogy a legnagyobb teljesítményen üzemeljen. Ahhoz, hogy ez a probléma megoldódjon, és a processzor 72MHz-en, zéró várakozási idővel tudjon működni, a flash memóriában egy előfetchelő puffer található, mely két, 64 bites pufferből épül fel. Minkét puffer 64 bit széles olvasási sebességgel tud olvasni a flash memóriából, majd minden egyes, 16 vagy 32 bites utasítást, a Cortex CPU-hoz juttatja végrehajtásra. Ez a technika a Thumb-2 utasításkészlet feltételes végrehajtási tulajdonságaival és a Cortex pipeline elágazás becslésével működik jól. Normál esetben a programozónak, a flash puffer miatt, nem kell különleges elővigyázatossági lépéseket tennie. Azonban meg kell bizonyosodnia afelől, hogy ez üzemel-e, mielőtt a PLL-t fő órajel forrásnak teszi meg. A flash puffert, a flash hozzáférés irányító regiszter vezérli. Az elő fetch-elő puffer aktiválása után, a flash elő fetch-elő puffere számára szükséges várakozási állapotok számát be kell állítani, hogy a 8 bájtos utasításokat olvasni tudja a flash memóriából. A késleltetési beállítások a következők: - 0< SYSCLK <24MHz 0 waitstate - 24< SYSCLK <48MHz 1 waitstate - 48<SYSCLK <72MHz 2 waitstate Ezek a várakozási állapotok a prefetch puffer és a flash memória között vannak, nem befolyásolják a Cortex CPU-t. Mialatt a processzor azokat az utasításokat hajtja végre, melyek a puffer első felében találhatók, a második felében lévőket betölti, így a CPU látszólag folyamatosan tudja végrehajtani az utasításokat, optimális sebességgel. A következőkben áttekintem a DMA egység, azaz közvetlen memória hozzáférést biztosító komponens működési eseteit. A perifériák és a belső SRAM közti adatmozgatási műveletek közül sok automatizálható a DMA egység segítségével, ezzel tehermentesítve a Cortex processzort. Az mikrokontroller DMA egysége hét, egymástól független konfigurálható, adatátvitelre alkalmas csatornája van, melyek automatikus adatátvitelre képesek memória és memória (2.9. ábra), periféria és memória, memória és periféria és periféria és periféria között. A memória és memória

20 12 közti átvitel olyan gyorsan végbemegy, amilyen gyorsan a DMA csatorna képes továbbítani az adatot. Periférikus adatátvitel esetében a DMA egység az adott periféria irányítása alatt van és az adat kérésre áramlik a perifériától, vagy a periféria felé. Adatblokkok szállítása esetén, minden DMA egység folyamatosan képes adatot továbbítani egy cirkuláris puffer felé. Mivel a legtöbb kommunikációs periféria nem rendelkezik FIFO pufferrel, így a DMA egységek használatosak arra, hogy továbbítsák az adatot a pufferektől vagy pufferekhez az SRAM memóriában. A DMA egységet kifejezetten a Cortex processzorhoz tervezték és emiatt rövid, de azonnali adatátvitelre optimalizálták, ahogy ezt általában a mikrokontroller alkalmazások megkövetelik ábra: a DMA memória - memória átvitel folyamata [1] Minden DMA átvitel négy fázisból tevődik össze (2.9. ábra): egy kiválasztó és döntési, egy cím kiszámító, egy busz kapcsolódási és végül egy nyugtázó fázisból. Minden fázis egy ciklusból áll, kivéve a busz kapcsolódási fázist. Ez a fázis ugyanis ahol az adatátvitel történik 3 ciklusból áll, minden szóátvitelre. A DMA egység és a Cortex processzor úgy lett megtervezve, hogy felváltva együtt működjenek egymással, így a DMA nem blokkolja a processzort és a processzor sem blokkolja a DMA egységet. Az alkalmazás szoftver minden egyes DMA csatornát négy prioritási szintre képes beállítani. Az arbitrációs fázis alatt a legmagasabb prioritási szintet a busz kapja. Ha két DMA egységnek függőben levő átvitelei vannak és mindkettőnek ugyanaz a prioritási szintje, akkor a legalacsonyabb csatornaszámmal rendelkező kapja a buszhoz való hozzáférést (2.10. ábra) ábra: a DMA egység BUS foglalása [1]

21 13 A DMA egység mind az arbitrációt, mind a címszámítási fázist el tudja végezni, amíg egy másik DMA csatorna a busz csatlakozási fázisban van. Amíg az aktív csatorna befejezi az adatátvitelét a belső buszon keresztül, a következő DMA csatorna készen áll, hogy azonnal elkezdje az adattovábbítást. Így a DMA nem csak gyorsabban tud adatot küldeni a CPU-nál, de szélesebb összefésülésre is képes, csak adatátvitelre foglalja le a buszt. A memóriából memóriába történő átvitel esetén, minden DMA csatorna lefoglalja az adatbuszt a busz kapcsolódási fázisa alatt és minden adatszó átvitelére öt ciklust használ fel. Az első ciklusban olvassa az adatot, a másodikban írja, közben tétlen ciklusokat iktat be, hogy a Cortex processzor is tudja használni a buszt. Ez azt jelenti, hogy a DMA egységek a busz sávszélességének legfeljebb a 40%-át fogják kihasználni, a maximális, folyamatos adatátvitel alatt. A perifériától perifériáig és a perifériától a memóriáig történő átvitel esete valamelyest bonyolultabb. Az AHB buszon keresztüli adatátvitel az AHB órajel frekvenciája mellett két ciklus, az APB buszon történő átvitel az APB frekvenciája mellett szintén két ciklus, továbbá két ciklust szükséges az AHB órajel frekvenciája függvényében. Minden DMA átvitel két busz átvitelt és egy szabad ciklusú periódust vesz igénybe. Tehát például az SPI periféria és a SRAM közötti átvitel tartalmazni fog egy transzfert az SPI-től, egyet az SRAM felé, továbbá egy szabad ciklust. SPI -> SRAM DMA transzfer = SPI transzfer(apb) + SRAM transzfer(ahb) + szabad ciklus (AHB) = (2 APB cilus + 2 AHB ciklus) + 2 AHB ciklus + 1 AHB ciklus = 2 APB ciklus + 5 AHB ciklus Ezek mind adattovábbításra értendőek, az utasítások fetch-elése a független I-BUS-on történik. A DMA egység használata nagyon egyszerű. Az első dolog, amire ügyelni kell, hogy az órajele be legyen állítva és egy reset segítségével fel legyen szabadítva. Ezt az AHB clock enable regiszter beállításával lehet megtenni, a reset és clock control egységen belül. RCC->AHBENR = 0x ; // enable the DMA clock Amint a DMA egység üzemkész, minden egyes csatornája négy regiszter segítségével vezérelhető. Két regiszterhez tartozik a perifériákhoz és a memóriahelyekhez tartozó forrás és cél címek. Az átvitel mérete a number of data regiszterhez tartozik és a konfigurációs regiszterhez definiálja a DMA átvitel teljes karakterisztikáját. Minden DMA csatorna négy féle prioritási szintet vehet fel: nagyon magas, magas, közepes és alacsony. Az átviteli szóméret külön meghatározható a memória és a periféria számára.

22 14 Lehetőség van a memória és periféria címek inkrementálására. Így egy perifériától ismételten érkező adatsort úgy tárolhatunk a memóriában, hogy az egymást követő területen, sorban helyezkedjen el. A transfer direction bit segítségével beállítható az adatáramlás iránya, azaz memóriából perifériába, vagy az ellenkező irányba történjen. Memóriából memóriába történő átvitelhez be kell állítani a 14-es bitet, hogy a lehető leggyorsabb mód aktiválva legyen két SRAM puffer között. A DMA csatornák használhatók polled módban. Minden DMA csatorna három megszakítási forrással rendelkezik: átvitel befejezve, félig befejezve és átviteli hiba. Végül, amint a DMA átvitel teljes mértékben konfigurálva van, a Channel Enable Bit-et be kell billenteni és az átvitel elkezdődik ábra: a DMA támogatást élvező perifériák kérési prioritásai [1] Minden olyan perifériának, mely DMA támogatást élvez, kiosztható egy specifikus csatorna (2.11. ábra). Amikor ez aktiválásra kerül, a periféria lesz a DMA átvitel folyamvezérlője. Ez lehetővé teszi, hogy adatnyelőként vagy forrásként működjön úgy, hogy közben CPU ciklusidőt nem kell igénybe vennie. Míg a memóriából memóriába történő adatátvitel alkalmas arra, hogy memóriarégiókat inicializáljon, és blokk átviteleket teljesítsen, az idő nagy részében, a DMA csatornák memória és különböző felhasználói perifériák közötti adatátvitelen dolgoznak. Ebben az esetben a csatornák a kiválasztott perifériák között oszlanak meg Első lépésben inicializálni kell a perifériát, majd aktiválni a DMA támogatását, ezután konfigurálni kell a hozzá tartozó csatornát az adatátvitelre, mely a támogatott periféria kérésére zajlik le. DMA nélkül a CPU munkáját folyamatos megszakítások gátolnák, melyek értékes processzoridőt emésztenének fel.

23 15 A perifériák nem tartalmaznak belső puffereket. A DMA-t cirkuláris módban használva, a memória minden része periféria pufferként használható. Ez kombinálható a DMA félig illetve teljesen befejezett megszakításaival, hogy egy körkörös dupla puffer jöjjön létre. Ahhoz, hogy ez a folyamat még hatékonyabb legyen, aktiválható a körkörös puffer támogatás. Ezután a félig befejezett és befejezett interrupt-ok segítségével létrehozható egy dupla puffer. Így amikor a puffer első fele megtelt, egy megszakítás generálódik és feldolgozhatjuk az adatot, amíg a DMA befejezi a puffer második felének feltöltését. Amint a második fél is feltöltődött, az adat feldolgozható lesz, amíg a DMA elkezdi fentről újratölteni a puffert. Minden DMA támogatott periféria ugyanolyan módon kezelhető. A kommunikációs perifériák azonban elkülönülő küldő és fogadó DMA csatornákat használnak. Például az SPI szimultán képes adatokat küldeni és fogadni mindkét irányban. Végül tanulmányoztam a programtárolók tartalmának módosítási lehetőségeit. Elsősorban a flash memória programozásának módját tekintettem át, melyet a továbbiakban ismertetek. A programtárolók tartalma módosításának ismerete fontos volt számomra, mivel munkám során az egyik feladatom volt, hogy a hálózaton átküldött mikrokontroller program végül a célprocesszor memóriájába íródjon. Az ARM processzorok tervezésének egyik fő filozófiai alapja, hogy a processzor a lehető legegyszerűbb legyen. A CPU RISC felépítést követ, kevés számú, egyszerű utasítással működik. Emellett magas teljesítményt nyújt alacsony fogyasztás mellett. A processzálás gyorsítása érdekében pipeline eljárással végzi a fetch-decode-execute feldolgozási folyamat lépéseit. Tehát, egy párhuzamos számítógép architektúráról beszélhetünk Flash memória programozás [2] A belső flash memória két memóriabankból áll. A programozónak, ennek ellenére nem kell törődnie ezzel, mivel számára ez egy darab, egybefüggő memóriaterületnek látszik, mely 8Kbyte-os szektorokra van felosztva. Ezek egymástól függetlenül törölhetők és programozhatók. Több módja van a flash memória programozásának. A legegyszerűbb, ha a beépített bootloaderre bízzuk ennek végrehajtását, mely beégeti a kívánt programkódot az UART0 vezérlőn keresztül a RAM, majd innen a flash memóriába. Használhatunk JTAG-et is. Ennek előnye, hogy rajta keresztül hibakeresést is végezhetünk. Végül lehetőség van arra, hogy a feltöltött alkalmazás program módosítsa a flash tartalmat, szektorok újraprogramozásával. Erre az esetre minden rendelkezésre álló megoldás alkalmazható: SPI, CAN és I2C. A következő fejezetben a három eljárás közül az utolsót ismertetem.

24 Alkalmazásból történő programozás [2] A flash memória újraprogramozására lehetőség nyílik a felhasználói programból. A bootloader parancsok egy API-n keresztül állnak rendelkezésre és a programkódból hívhatók. A bootloader függvényeinek eléréséhez a ROM-ban létre kell hozni egy táblát, mely tartalmazza annak a függvénynek a parancskódját, amit használni szeretnénk a megfelelő paramétereket megadva. A tábla kezdőcímét az R0 regiszterben tárolták. Az R1 regiszter tartalmazza a második táblát, melyben a státusz kód és a függvény futásának eredménye szerepel (2.12. ábra) ábra: a bootloader függvények elérése a felhasználói programból [2] A program belépési pontja a 0x7FFFFFF0 helyen van, ha a THUMB függvényből szeretnénk függvényeket hívni, vagy lehet a 0xFFFFFF1 ponton, ha ARM függvényből szeretnénk indulni. A visszatérési cím a link regiszterben tárolódik. void iap (unsigned *cmd, unsigned *rslt, unsigned entry) { asm( mov r15,r2 ); }

25 17 THUMB módban a high regiszterek nem programozhatók közvetlenül, csak indeirekt, low regiszterek tartalmát mozgathatjuk át azokba. Amint a az IAP rutin befejezte a működését, a vezérlés visszatér, és a program végrehajtása folytatódik ARM módban. Az IAP függvényei futásához szükség van a chipen található RAM memória felső 32 byte-jára. Tehát ezt a területet szabadon kell hagyni. A TFTP szerverrel feltöltött programkódot bootloader segítségével indítom el. Ha a feltöltés hibás volt, a reset után az egyik gomb megnyomásával indítható a TFTP szerver, mely segítségével újra letölthető a programkód, ezzel lehetséges a hiba javítása. 2.3 Beágyazott rendszerek hálózati kommunikációja [3] Annak érdekében, hogy egy beágyazott rendszer kommunikálni tudjon a környezetében lévő eszközökkel, megfelelő kapcsolatot kell tudnia létesíteni velük. A TCP/IP protokoll család alkalmas ennek a feladatnak az ellátására legyen szó vezetékes vagy vezeték nélküli összeköttetésről. A következőkben példákon keresztül bemutatom, hogy milyen konfigurációk képzelhetők el az összeköttetés szempontjából és röviden bemutatom azokat a protokollokat, melyeket a tervezés során kiválasztottam, majd felhasználtam a feladatom megvalósításához. A TFTP protokoll ismertetésével külön fejezetben foglalkozom. Mikrokontroller mikrokontroller: ábra: kapcsolat két mikrokontroller között [3] Az alkalmazás mikrokontrolleren, vagy több mikrokontrollerből álló konfiguráción fut (2.13. ábra).

26 18 Mikrokontroller PC: ábra: kapcsolat mikrokontroller és PC között [3] Ebben az esetben a mikrokontroller adatokat szolgáltat vagy vár a PC-től. A feldolgozás az erőforrásokkal jól ellátott személyi számítógépen történik (2.14. ábra). Feladatom során ezt az elrendezést alakítottam ki. A TFTP szerver a mikrokontrolleren fut, melyet a PC, TFTP kliensen keresztül ér el. Multi Drop hálózat: ábra: Ethernet vagy más multi-drop hálózat [3] Egy kommunikációs hálózatra több mikrokontroller és PC csatlakozik (2.15. ábra) Az UDP protokoll A TFTP protokoll UDP protokoll segítségével továbbítja az információt. Az UDP egy nem kapcsolatorientált, nem megbízható, adatátviteli eljárás, mely egymástól független módon juttatja el a csomagokat a feladótól a címzetthez. Hiba esetén a csomagot eldobja, hibaüzenetet nem küld, erről a magasabban lévő, alkalmazás réteg gondoskodhat. Az UDP mindössze abban különbözik az IP protokolltól, hogy port számot és opcionális ellenőrző összeget tartalmaz. [4] Hátrányai ellenére mégis nagyon hasznos, mivel kis erőforrás igényű, csomagonként minimális overhead-et tartalmazó, gyors és egyszerűen megvalósítható, különösen alkalmas mikroprocesszoros alkalmazásra.

27 ábra: az UDP datagram felépítése [4] UDP alapú adatátvitel esetén nincs kapcsolat felépítés és bontás a két kommunikáló fél között. [5] A csomagok a forrás és cél port illetve az IP címek alapján utaznak a hálózaton. A hossz mező bájtban adja meg a fejrész és adatrész hosszának összegét, értéke minimum 8, ez abban az esetben lehetséges, ha az UDP csomag csak fejrészt tartalmaz. Az ellenőrző összeg a szokásos egyes komplemens összeadás eredménye. Nem kötelező használni, de erősen ajánlott. [4] Kapcsolat létrehozás: Ahhoz, hogy egy alkalmazás egy távoli gépen futó programmal kapcsolatot tudjon létesíteni információra van szüksége. Ilyen információ az IP cím és a port szám IP cím: Az IP cím egy 32 bites egész szám. A hálózatra kapcsolt eszközöket ennek segítségével lehet rendszerbe illeszteni. Az IP szintű csomagtovábbítás ennek segítségével megy végbe Port szám: A port szám egy 16 bites egész szám. Multi taszkos környezetben, ahol egy mikroprocesszoron több program fut egyszerre, melyek külön-külön hálózati kommunikációt akarnak folytatni, nem elég egy IP cím a csomagok demultiplexálásához. Ez a szám ezt a problémát hivatott feloldani oly módon, hogy minden egyes, a processzoron futó alkalmazást egyedileg azonosít. A portoknak két típusát különböztetik meg:

28 20 Well-known portok: Általában az 1024-nél kisebb természetes számok, melyeket definiáltan egyes TCP/IP alkalmazásokhoz rendeltek. Az operációs rendszerek korlátozzák az ezekhez való hozzáférést. pl.: TFTP 69, HTTP 80. [5] Ephemeral portok: Az 1024-nél nagyon természetes számok, a kliensek ephemeral portokat választanak a maguk oldalán. [5] Egy kommunikációs végpontot egy IP cím és egy port szám határoz meg, melyet socket-nek neveznek Kliens-szerver alkalmazások: Két alkalmazás közötti információcsere egyik bevált módja, a kliens-szerver modell. A feladatom megoldásához ezt az elvet használtam fel. Az egyik programnak a kliens, a másiknak a szerver szerepét kell betöltenie. A kliens alkalmazás létrehoz egy socket a processzor IP címe és egy port szám segítségével, majd aktív módon kapcsolódik a szerverhez. A szerver ez alatt a saját socket-jén passzívan várja a kapcsolódni kívánó klienseket. Amikor észleli, hogy kapcsolódni szeretnének hozzá, elfogadja a kérelmet és ezután indulhat az információáramlás Adatkapcsolati réteg Ethernet, ARP: Az Ethernet a legelterjedtebben alkalmazott, csomag alapú, helyi hálózati protokoll, mely a csomagok ütközésének problémáját CSMA/CD eljárással oldja fel ábra: az Ethernet frame felépítése [7] A preambulum 56 bit, váltakozó 0 és 1-eseket tartalmaz, melyek segítségével szinkronizál a vevő. A következő mező jelzi, hogy hol kezdődik az érdemi információ. (2.17. ábra) 1 bájt adat váltakozó 1-esek és 0-ák, ahol az utolsó két bit 1-es: Következik a cél cím és a forrás cím, melyek egy-egy Ethernet címet jelentenek. A cél cím lehet unicast, multicast és broadcast. A hossz vagy típus mező megadja a csomag hosszát, ha ez 1500 bájtnál nagyobb, akkor típust jelöl. Ezután következik az adat, majd egy kiegészítő rész, amit akkor használ, ha az adat 46 bájtnál kisebb lenne. Végül a

29 21 hibadetektáláshoz szükséges CRC kód, melyet a cél címtől az adat, vagy a Pad-el kiegészített adat végéig számol. Ha a CRC hibát jelez, a csomag eldobásra kerül. Minden Ethernetet használó chipnek egyedi, 48 bites azonosító száma van, melyet MAC, azaz Media Acces Control címnek neveznek. Az adatkapcsolati rétegben, a legalsó, fizikai réteg fölött helyezkedik el a hierarchiában. Ebben a rétegben található egy további fontos protokoll, az ARP Address Resolution Protocol. Ez hivatott kapcsolatot teremteni a MAC és az IP címek között. A hálózati kommunikáció során a csomagok az IP cím alapján jutnak el egyik alhálózatból a másikba, a MAC vagy más néven Ethernet címek pedig arra szolgálnak, hogy a multi-hop, több állomáson keresztül utazó információ, két pontja között terjedni tudjon. Folyamat: Amikor egy processzor kommunikálni kíván egy rendelkezésre álló IP címmel adott másik processzorral, az első teendője, hogy megnézi az ARP táblájában szereplő IP MAC cím párokat. Ha szerepel benne az IP cím, akkor megkezdi az adatküldést, ha nem akkor egy broadcast üzenetet küld a hálózatra, melyet minden eszköz megkap. Erre unicast formában válasz az az eszköz, mely felismeri a saját IP címét. Az üzenetben elküldi a hozzá tartozó MAC címet. Ekkor a kérdező processzor frissíti a MAC tábláját és az új adat birtokában megkezdi az adatküldést.

30 22 3 Az FTP és a TFTP protokoll összehasonlítása A File Transzfer Protocol és a Trivial File Transfer Protocol a TCP/IP hálózatok klasszikus állomány átviteli szabványai. A diplomaterv feladatom pontos kitűzése előtt, gondosan tanulmányoztam a két eljárást azért, hogy a célkitűzéseim alapján ki tudjam választani a legmegfelelőbbet. Ebben a fejezetben részletesen ismertetem a két protokollt, majd összehasonlítom őket, végül felsorolom az indokokat, amik alapján meghoztam a döntést és kiválasztottam a számomra legmegfelelőbb módszert. 3.1 A File Transfer Protocol [8][9] Az FTP File Transfer Protocol-t egy széles körben elterjedt alkalmazás, a sztenderd fájlátvitel internetes szabványa. A hivatalos specifikációját az RFC 959 tartalmazza. Használatához szükség van egy felhasználói fiókra az FTP szerveren, de alkalmazható ennek hiányában is, ha a kiszolgáló biztosítja ezt a lehetőséget (anonymous FTP). Az FTP elterjedt alkalmazását mi sem bizonyítja jobban, mint, hogy a legtöbb internetes böngésző program támogatja a használatát. Sok esetben a felhasználó észre sem veszi, hogy ezt a fájlátviteli protokollt vette igénybe. A Telnethez hasonlóan az FTP-t is úgy alakították ki, hogy különböző operációs rendszereket futtató, eltérő fájlrendszert és karakterkészletet használó állomások között is képes legyen működni. Az FPT protokollt a szállítási rétegben elhelyezkedő, TCP protokoll fölé tervezték. (3.1. ábra) 3.1. ábra: a TCP/IP rétegek [6]

31 23 Két TCP kapcsolaton alapul (3.2. ábra): Vezérlő vagy kontroll kapcsolat: a kliens ephemeral vagy más szóval véletlen portjáról, azaz egy 1024-es sorszámnál nagyobb portról, a szerver 21-es portjára kiépülő kapcsolat. Adatkapcsolat: a szerver a 20-as portjáról, a kliens által megadott portra építi fel. Ezt aktív FTP-nek hívjuk. Passzív esetben a kliens építi ki a kapcsolatot a szerver felé ábra: az FTP alkotóelemei [12] Az utasítások, és az ezekre érkező válaszok, a kontroll kapcsolaton utaznak. Az utasítások az emberi szem számára is könnyen érthető, ASCII karakterekből álló stringek. Ennek köszönhetően az FTP fejlesztése és a hibakeresés is könnyű. A szerver válaszüzenetei három decimális számmal kezdődnek, majd utána a felhasználónak szóló, angol nyelvű szöveggel folytatódnak. A vezérlő kapcsolat a szerver-kliens kommunikáció során végig nyitva marad, ezzel szemben minden egyes fájlátvitelhez új adatkapcsolat épül ki. A két kapcsolattípushoz különböző IP type-of-service paramétert használ: a vezérlő kapcsolat esetében a minimális késleltetésen van a hangsúly, mivel a parancsok általában humán forrástól származnak, az adatkapcsolatnál viszont a maximális áteresztőképességen, hiszen az adatátvitel ezen keresztül bonyolódik le. Az FTP protokoll esetében számos adatreprezentációs mód áll rendelkezésre. Az alapértelmezett fájltípus az NVT ASCII kódolást használja. Ehhez mind a küldő, mind pedig a fogadó félnek adatkonverziót kell biztosítania, ha az általa használt fájltípus eltérő kódolású. Lehetőség van EBCDIC kódolás használatára, ha az adatátvitelben szereplő mindkét fél ebben a rendszerben működik. Használható továbbá bináris mód, ahol az adat egy bitfolyamként cserél gazdát. Végül a különböző bitszámból álló bájtokat definiáló rendszerek között is képes lebonyolítani az adatátvitelt.

32 24 EBCDIC(Extended Binary Coded Decimal Interchange Code): A 6 bites BCD kódolás, mely csak nagybetűk, számok és speciális karakterek kódolását tette lehetővé, kibővítése oly módon, hogy kisbetűs karakterek és kiegészítő információk tárolására is képes legyen. A 8 biten reprezentálható 256 értékből nincs mindegyik kihasználva. Az I és R karakterek után szakadás (üres karakter) következik. Ennek köszönhető, hogy ez a rendszer nem terjedt el, főleg az IBM használta. ASCII(American Standard Code for Information Interchange): Az Amerikai Nemzeti Szabványügyi Hivatal által, az információcseréhez kidolgozott kódrendszer, mely 7 biten, 128 karaktert képes ábrázolni. A betűk kódjának inkrementálása során a helyes ABC sorrendet kapjuk, a Z betű kódjának kivételével. Formátum kontrollra kizárólag az EBCDIC és az ASCII típusú fájlok kapcsán van lehetőség. Az alapértelmezett mód az úgynevezett Nonprint, amikor a fájl nem tartalmaz vertikális formátumra vonatkozó információt. Lehetőség van továbbá Telnet formátum kontroll és Fortran carriage kontroll nyomtatási információk használatára. A struktúra alapértelmezésben egy fájlszerkezet, ahol a fájlokat bitek folyamaként kezeli. EBCDIC és ASCII kódolású szövegfájlok esetén lehet rekord felépítésű. Továbbá használható lapszerkezetű struktúra is. Végül szót kell ejteni az átviteli módokról, ugyanis ezek specifikálják, hogy a fájlok, miként haladnak keresztül az adatkapcsolaton. Az FTP protokoll három átviteli sémát kínál: adatfolyam (stream), blokk, és tömörített (compressed) mód. Az adatfolyam mód az alapértelmezett. Ebben az esetben a fájlok bájtfolyamként utaznak a szerver és kliens között. Fájlrendszer esetében a fájlok végét az jelzi, hogy a küldő lezárja az adatkapcsolatot. Blokk módban, fejrész információval ellátott blokkok sorozataként, ahol a fejrész hosszból és leírásból áll. A tömörített mód csak ritkán támogatott és nem javasolt a használata, mivel rendelkezésre állnak hatékonyabb tömörítési eljárások. Az tömörítést oly módon éri el, hogy az egymást követő egyforma bájtokat rövidítve kódolja. Az FTP kontroll kapcsolaton a kliens egysoros, angol nyelvű kulcsszavakból álló, CR/LF-fel záródó parancsokat ad. Ezért lehetséges Telnet klienssel, FTP emulációt végezni. Az FTP szerver válaszai 3 jegyű decimális számmal kezdődnek, majd a felhasználónak szóló szöveggel folytatódnak. A program csak a számkódot vizsgálja. A legnagyobb helyiértéken található számjegy jelzi a sikerességet. 1 = részleges, előzetes sikeres válasz 2 = siker 3 = részleges, közbülső állapotot jelző sikeres válasz 4 = átmeneti sikertelenség

33 25 5 = végleges sikertelenség Az FTP adatkapcsolat a kontroll kapcsolattól független. Két féle kapcsolat felépítési módot különböztetünk meg: aktív és passzív. Aktív kapcsolatnyitáskor a kliens megad egy portot a szervernek, amire kiépítheti az adatkapcsolatot. Ez az eljárás nem kedvelt, mert általában a tűzfalak konfigurációjakor nem előnyös megengedni, hogy a védett gépre kívülről, TCP kapcsolat nyisson egy távoli hoszt. Erre a problémára kínál megoldást a passzív FTP. Ebben az esetben a kapcsolat ellenkező irányból épül fel, a szerver megad egy portot a kliensnek, amire az utóbbi felépíti az adatkapcsolatot. A manapság legelterjedtebb FTP használati mód, az anonymous FTP. A nyilvánosan olvasható fájlok közzétételének egyszerű módja. A szerver ugyan kér jelszót, de ez általában csak a felhasználó címét jelenti, aminek hitelességét nem ellenőrzi. 3.2 A Trivial File Transfer Protocol [10] A TFTP - Trivial File Transfer Protocol egy nagyon egyszerű protokoll, melyet fájlátvitelre használnak. A protokollt eredetileg Noel Chiappa tervezte, majd Bob Baldwin és Dave Clark gondolta újra Steve Szymanski megjegyzéseit figyelembe véve. A nyugtázás és az újraküldés sémáját a TCP protokoll ihlette. A hiba mechanizmust pedig PARC EFTP abortáló üzenete sugallta. A TFTP szabványt az UDP protokoll fölé tervezték, ezáltal a fájlátvitel olyan gépek között is végbemehet, melyek különböző típusú hálózatokhoz csatlakoznak, de ismerik az UDP protokollt. (Ez nem zárja ki annak lehetőségét, hogy TFTP-t más adatátviteli protokoll felett valósítsuk meg.) A tervezés során az volt a cél, hogy kicsi és könnyen implementálható legyen. Ezért az FTP protokoll legtöbb tulajdonsága hiányzik belőle. Az egyetlen dolog, amit tud, a fájlírás/olvasás (vagy levelezés) oda/vissza egy távoli szerverrel. Nem képes mappákat listázni és jelenleg nincs felhasználó azonosító szolgáltatása sem. Más Internet protokollokkal egyetemben ez is 8 bájtos részekben viszi át az adatot. Mostani formájában az átvitel három formája támogatott: netascii (8 bit ASCII); oktet (nyers 8 bit bájtok); mail (netascii karaktereket küld a felhasználónak fájlként). A levelező mód elavult, és nem feltétlenül kell megvalósítani, illetve használni. További eljárások definiálhatók host páronként (mindkét fél esetében implementálni kell).

34 ábra: a TFTP csomag felépítése [11] Minden átvitel azzal kezdődik, hogy egy kérést küldünk egy fájl írására vagy olvasására és ezzel együtt egy kérést kapcsolat létrehozására. Ha a szerver elfogadja a kérést, akkor a kapcsolat megnyílik, és a fájlátvitel megkezdődik fix 512 bájtos blokkokban. A protokoll stop-and-wait elven működik. Minden adatcsomag egy adatblokkot tartalmaz és a következő csomag elküldése előtt kötelezően meg kell érkeznie egy nyugtának, mielőtt a további küldés folytatódik. Ha egy adatcsomag (3.3. ábra) kisebb, mint 512 bájt, akkor ez az adatküldés végét jelenti, az átvitel leáll. Ha egy csomag elveszik a hálózaton, a megcélzott fogadó time-out állapotba kerül majd a csomagja ismét elküldésre kerül (lehet csomag vagy nyugta) ezzel késztetve az elveszett csomag küldőjét, hogy újraküldje a csomagot. A küldőnek csak egy csomagot kell megtartania újraküldés céljára, mert az előző lezáró nyugta garantálja, hogy az összes megelőző csomag célba ért. Az adatátvitelben szereplő mindkét gép küldő és fogadó egyben. Az egyik adatokat küld és nyugtákat fogad, a másik nyugtákat küld és adatokat fogad. A legtöbb hiba a kapcsolat megszakadása miatt következik be. A hibajelzés egy hibacsomag elküldésével történik. Ezt a csomagot nem kell nyugtázni sem újraküldeni, mert a kapcsolat másik végén lévő lehet, hogy meg sem kapja ezt. Ezért a time-out-ot használjuk kapcsolat megszakítás észlelésére, ha a hibacsomag elveszett. Hibák három dolog miatt következhetnek be: nem tudjuk kielégíteni a kérést (pl: fájl nem található, kapcsolódás megtagadva, nincs ilyen felhasználó), olyan csomagot kapunk, mely nem fér bele a késleltetési időbe vagy kétszer fordul elő a hálózaton (pl: rosszul formázott

35 27 csomag) és elvesztettük a kapcsolatot egy szükséges erőforrással (pl: megtelt lemez, hozzáférés megtagadva a küldés alatt). A TFTP csak egy hibakörülményt ismer el, ami nem okoz kapcsolatbontást: a fogadott csomag forrásportja hibás. Ebben az esetben egy hibacsomag megy az eredendő hosthoz. A TFPT protokoll nagyon korlátozó, annak érdekében, hogy egyszerűsödjön a megvalósítása. Például, a fix hosszúságú blokkok sorfolytonosan allokálódnak, és a végső csomag intézkedik a folyam kontrollról és emiatt nincs szükség a bejövő csomagok újrarendezésére. Ahogy említettem a TFTP-t úgy tervezték, hogy az UDP protokoll felett legyen megvalósítható. Mivel az UDP datagramm az IP protokoll felett helyezkedik el, a csomagok Internet fejrésszel, datagram fejrésszel és TFTP fejrésszel is rendelkeznek. (3.4. ábra) Továbbá, a csomagoknak lehetnek olyan fejrészei is (LNI, ARPA stb.), mely átengedi őket a helyi szállító közegen. Ahogy az ábra mutatja a csomagok tartalmának rendje a következő: helyi médium fejrész, ha van, IP fejrész, UDP fejrész, TFTP fejrész követi a TFTP csomag maradék részét. (Ez lehet, hogy adat, de lehet, hogy nem, attól függően, hogy mi a TFTP fejrészben meghatározott csomag típusa?) A TFTP nem specifikál egyetlen értéket sem az IP fejrészben. A másik oldalon a forrás és a cél porton viszont az UDP fejrészt használja a TFTP és a hossz mező rávilágít a TFTP csomag hosszára. Az átviteli azonosítókat (TID-ket) melyeket a TFTP használ, az adatkezelő rétegnek engedi át, hogy portként használja őket, ezért ezeknek 0 és között kell lenniük ábra: a TFTP fejrész felépítése [10] alapján A kapcsolat felépítés egy kérés elküldésével indul (WRQ: írás egy távoli fájlrendszerbe, vagy RRQ olvasás onnan), és egy pozitív válaszüzenet fejeződik be, ami vagy egy ACK üzenet az írásra, vagy az első csomag az olvasni kívánt adatból. Általában a nyugtázó üzenet tartalmazza annak az adatcsomagnak a blokk számát, melyet ő nyugtáz. Minden adatcsomaghoz társul egy blokk szám; a blokk számok egymást követik és eggyel kezdődnek. Mivel az írási kérelemre érkező pozitív válasz egy nyugtázó csomag, ebben a speciális esetben a blokk szám nulla. (Rendes esetben mivel egy nyugtázó üzenet egy adatcsomagot nyugtáz, a nyugta csomag az adatcsomag blokk számát fogja tartalmazni, amit nyugtáz.) Ha a válasz egy hibaüzenet, a kérelem visszautasításra kerül.

36 28 Annak érdekében, hogy létrejöjjön a kapcsolat, mindkét fél választ magának egy TID-t, amit a kapcsolat alatt fognak használni. Ezeket a TID-ket átadja az UDP rétegnek (vagy más datagram protokollnak) mint forrás és cél portokat, mely kiszolgálja a TFTP-t. A kérő host kiválasztja a saját forrás TID-ját, ahogy fent írva vagyon, és elküldi a kezdeti kérését az ismert 69-es (69 tízes, 105 nyolcas számrendszerben) TID-vel rendelkező, kiszolgáló host felé. A kérésre érkező válasz, normál működés közben, a szerver által kiválasztott TID-t használja forrás TID-jának, és az a TID melyet az előző üzenethez választott a kérő lesz a cél TID. A két választott TID az átvitel végéig használatban marad. Példaként a következő eset bemutatja egy írás fájlba-célú kapcsolat felépítésének lépéseit. A WRQ, ACK és DATA rendre az írási kérelem neve, nyugta és a csomag adattípusa: 1. Az A host küld egy WRQ -t a B hostnak az A TID-jával, mint forrással, a célport pedig A B host küld egy ACK -ot (melyben a blokk szám 0) az A hostnak melyben a forrás a B TID-ja, a cél pedig A TID-ja. Ezen a ponton a kapcsolat felépült és az első adatcsomag küldhető az A host-ról 1-es szekvencia számmal. A következő és az összes elkövetkező sikeres lépésben, a hostoknak meg kellene bizonyosodniuk afelől, hogy a forrás TID illeszkedik-e ahhoz az értékhez, melyet az első és második lépésben elfogadtak. Ha a forrás TID nem illeszkedik, akkor a csomag eldobásra kerül, mint egy hibásan valahonnan ide küldött csomag. Egy hiba csomagot kell küldeni a hibás csomagot küldő forrásnak, mialatt ez nem zavarja az átvitelt. Ezt csak akkor kell elvégezni, ha a TFTP egy hibás TID-val rendelkező csomagot kap. Ha ezt a támogató protokollok nem teszik lehetővé, ez a hiba körülmény nem váltódik ki / adódik tovább. A következő példa bemutatja a protokoll egy helyes működését, melyet a fenti eset kiválthat: Az A host küld egy kérést a B hostnak. Valahol a hálózaton a kérést tartalmazó csomag megkétszereződik és ennek következtében két nyugta érkezik vissza A-hoz, különböző TIDval, melyeket a B választott, válaszul a két kérésre. Amikor az első válasz megérkezik, az A host folytatja a kapcsolódást. Amikor a második válasz is megérkezik a kérésre, vissza kell utasítani, de nincs ok arra, hogy a már létrejött kapcsolatot lezárja. Ennek következtében, ha különböző TID-k választódnak ki a két kapcsolathoz, a B és az A hoston, ellenőrzi a

37 29 fogadott üzenet forrás TID-ját. Az első kapcsolatot életben kell tartani, míg a másodikat, a visszatérő hibacsomag hatására vissza kell utasítani. A TFTP öt fajta csomagtípust támogat, melyek a következők: 1 Read request (RRQ) 2 Write request (WRQ) 3 Data (DATA) 4 Acknowledgment (ACK) 5 Error (ERROR) 3.3 Összehasonlítás és választás Feladatom megvalósításához a TCP/IP architektúra alkalmazási rétegéből két protokollt, az FTP-t és TFTP-t tanulmányoztam. Az FTP egy teljes, kapcsolat orientált, általános célú fájlátviteli protokoll, melyet TCP fölé terveztek. Összetett, megbízható protokoll, mely sok funkciót képes ellátni. Az implementálása bonyolultabb, erőforrásigényei nagyobbak mind processzor, mind pedig memória terén, két TCP kapcsolatot használ. Nagy RTT esetén gyorsabb a TFTP-nél. Interaktívan használható és lehetőséget ad felhasználó azonosításra. A TFTP egy speciális célú, UDP fölé tervezett, fájlátvitelre alkalmas, egyszerű protokoll. Működését kisebb erőforrásigény, alacsonyabb overhead jellemzi. Mivel az átvitel stop-endwait elvet követ - azaz egy adatszegmens elküldése után addig nem küld újat, amíg nem kap erre nyugtát, ha nem jön nyugta, akkor az utolsó szegmenst újraküldi - így nem képes teljesen kihasználni a hálózat nyújtotta maximális sávszélességet, mivel a tényleges átviteli sebesség nem csak a fizikai vonalak sebességétől, hanem a késleltetéstől is függ. Működése során jelentkezhet az úgynevezett Bűvészinas szindróma : ha a k-adik nyugta késik, de nem vész el, a k-adik adatot újraküldi a küldő. Idővel megérkezik a késett k-adik nyugta. A küldő küldi a k+1-edik adatot. Megérkezik az újraküldött, k-adikra küldött nyugta. A küldő küldi a k+1-edik adatot és ettől kezdve minden csomagot kétszer fog küldeni. [10] Egyik protokoll sem alkalmaz titkosítást az elküldött adatokra, ezért erről külön kellett gondoskodnom. A két protokoll közül a választásom a TFTP-re esett, mivel ezt alkalmasabbnak találtam egy kisebb erőforrással rendelkező, beágyazott rendszeren való működtetésre. Nagy előnye továbbá, hogy a működéséhez a kliens oldalon nem szükséges hozzá beavatkozási felület.

38 30 4 Titkosítási eljárások áttekintése [12] Feladatom megvalósításához Ethernet alapú hálózatot használok. Mivel a hálózaton továbbított programkód szellemi termék, ezért a tervezés során ennek védelméről is gondoskodnom kellett. A továbbiakban, a tanulmányozott irodalom alapján ismertetem az áttekintett titkosítási eljárások célját, fajtáit és működési módjait, majd bemutatom, hogy a kiválasztott módszer miért volt előnyös számomra. 4.1 Bevezetés A titkosítás használatának fő okai, hogy ne legyen olvasható, és vagy megváltoztatható a védeni kívánt dokumentum. A hálózati biztonság négy problémakör szerint osztályozható: - Titkosság - Hitelesség - Letagadhatatlanság - Sértetlenség A titkosság azt hivatott megakadályozni, hogy a hálózaton utazó dokumentum ne jusson illetéktelen kezekbe. A hitelesség garantálja, hogy bizonyíthatóan a megfelelő forrásból érkezik az információ. A letagadhatatlanság biztosítja, hogy a hálózati kommunikációban résztvevő egyik fél által küldött információt, később ne tudja úgy feltüntetni, mintha az nem tőle származna. Végül a sértetlenség annak záloga, hogy az elküldött dokumentum abban a formában jut el a címzetthez, mint ahogy a küldő elindította. Munkám során e négy szempont közül az első, második és a negyedik problémakörrel kellett szembenéznem. A hálózati biztonság kapcsán alkalmazott eljárások és módszerek az összes hálózati rétegre kiterjednek. A fizikai rétegben, az adatkábelbe töltött argon gáz nyújthat védelmet, melynek nyomáscsökkenése jelzi, ha külső behatolás történik, a vezetékre illetéktelenül akarnak csatlakozni. Az adatkapcsolati rétegben két pont között kódolják a csomagokat. Mivel így az összes felsőbb réteg fejrészét is titkosítják, így minden egyes áthaladási ponton vissza kell fejteni a kódolt csomagot, majd újbóli titkosítást alkalmazva küldeni tovább a következő állomásra. A módszer hátránya ebben rejlik, ugyanis minden egyes átviteli berendezés sebezhető pont, megfelelő eszközökkel csatlakozva hozzájuk, az adatcsomagok nyílt szövegként megszerezhetők. Előnye, hogy a felsőbb rétegektől független, azok működését nem befolyásolja. A hálózati, azaz az Internet Protokoll rétegben tűzfalakkal

39 31 szűrik a forgalmat és különböző IP biztonsági funkciókat használnak. A szállítási rétegben végpont-végpont közti teljes összeköttetés titkosítása lehetséges. A legnagyobb mértékű biztonság itt már elérhető. Az azonosítás pedig csak a hálózati rétegben valósítható meg. A felsorolt biztonsági eljárások mindegyike, a fizikai réteget leszámítva, a kriptográfia tudományterületén alapul. A továbbiakban a kriptográfia alapjait járom körül. A kriptográfia megkülönböztet rejtjelet és kódot. A rejtjel karakterről-karakterre, vagy bitről-bitre történő átalakítást jelent. A titkosítandó adatfolyam szerkezetét nem veszi figyelembe. A kód szót helyettesít másik szóval, vagy szimbólumot egy másikkal. Mindkét esetben a kódolni kívánt folyamot, melyet nyílt szövegnek nevezünk, transzformáljuk egy függvény segítségével, melynek paraméterét kulcsnak nevezzük. Az eredmény a titkosított szöveg. (4.1. ábra) 4.1. ábra: a titkosítási modell [12] alapján A szakirodalom a következő jelölést használja ennek matematikai leírásához: C = Ek (P), ahol C a titkosított üzenet, E a titkosító függvény, vagy algoritmus k kulcsparaméterrel és P a titkosításra szánt nyílt szöveg. P = Dk (C), ahol D a dekódoló függvény vagy algoritmus k kulcsparaméterrel A következő állítás a fentiekből adódik: Dk (Ek(P)) = P Kezdetben a titkosítással foglalkozó szakemberek arra törekedtek, hogy a titkosítást végző algoritmusok titokban maradjanak. A gyakorlat azonban azt a felismerést eredményezte, hogy ez nem szükséges, az algoritmusok nyilvánossága nem feltétlenül eredményezi azok

40 32 gyengülését. Ezt az elvet Auguste Kerckhoff, flamand hadikriptográfus fogalmazta meg 1883-ban. Kerckhoff elve: Minden algoritmusnak nyilvánosnak kell lennie, csak a kulcsok titkosak. A titkosítási eljárások kapcsán a kulcsok hosszúsága központi jelentőséggel bír. Egy rendszer feltörésének munkatényezője, a kulcstér elemeinek végigpróbálásával, a kulcs hosszával exponenciálisan nő. Titkosítási módszerek: A titkosítási eljárások két csoportra oszthatók: Helyettesítő kódolók Keverő kódolók A helyettesítő kódolók, a titkosítani kívánt szöveget úgy kódolják, hogy minden felhasznált karakterhez hozzárendelnek egy másik karaktert, vagy karakter csoportot, majd a nyílt szövegben található összes karaktert rendre kicserélik a hozzárendelési szabály alapján. Ennek a módszernek a klasszikus példája az úgynevezett Caesar kód, ahol az abc betűit egy körvonalra felfűzzük, majd a betűkhöz a körvonal mentén, az óramutató járásával megegyezően, hárommal távolabbi betűt rendeljük. Ennek továbbfejlesztett változata, ha a hozzárendelési szabályt egy táblázattal megadva úgy módosítjuk, hogy az abc betűihez tetszőleges betűket rendelünk. Ezt egybetű-helyettesítéses titkosításnak nevezzük. Így a feltörés, az összes lehetséges kombináció számítógépes végigpróbálgatásával sem valósítható meg belátható idő alatt. Sajnos az eljárás nagy hátránya, hogy a titkosított szöveg, az eredeti szöveg betű sorrendjéről és előfordulási statisztikájáról információt hordoz. Ezen elindulva, a kód viszonylag könnyen és rövid idő alatt megfejthető. A keverő kódolók megtartják az eredeti betű vagy karakteralakot, de egy kulcs segítségével megváltoztatják azok sorrendjét. 4.2 Egyszer használatos bitminta, a XOR titkosítás Ez a módszer is kulcs segítségével titkosít. Kizárólag a titkosított üzenet birtokában gyakorlatilag feltörhetetlen, mivel a titkosított szöveg nem tartalmaz olyan információt, amin elindulva fel lehet törni. Az eljárás lépései a következők: - Kulcsválasztás: a kulcs legyen egy véletlen bitsorozat, a legjobb eset, ha a kulcs hossza megegyezik a titkosítani kívánt nyílt szöveg hosszával. - A kódolandó nyílt szöveget bitsorozatként ábrázoljuk. Ez nem jelent problémát, mivel a számítógépek minden információt bitmintákban tárolnak.

41 33 - Kódolás: A nyílt szöveg és a kulcs bitjein rendre, párosával kizáró vagy műveletet hajtunk végre. A kapott, kódolt folyamban szereplő karakterek előfordulási valószínűsége egyenletes eloszlást követ. Jelenleg nem áll rendelkezésre olyan számítási kapacitás, amely ezt képes lenne feltörni, ugyanis a törés csak egy módon képzelhető el: a kulcsok végigpróbálásával. Az eljárás hátránya, hogy a kulcsról mindkét félnek, írott formában másolata kell, hogy legyen. Tetszőlegesen hosszú szöveg kódolásához nagyon hosszú kulcsot kell képezni. Nagyon érzékeny az elveszett, vagy közbeékelődött karakterekre. A kulcsot nem küldhetjük a hálózaton. A kriptográfiai eljárások alapvetően két alapelvre épülnek. Az egyik a redundancia, ami azt jelenti, hogy a szükségesnél több bitet használunk fel a titkosítás során. Ez a módszer, egy titkosított üzenetekkel működő rendszer ellen irányuló aktív támadások ellen használható. Aktív támadás alatt olyan támadást értünk, mely megfigyeli a hálózati forgalmat, majd a forgalomhoz hasonló, véletlenszerűen generált üzenetekkel árasztja el a szervert. Ezek között a dekódolást követően értelmes üzenetek is lehetnek, melyeket a rendszer gyanakvás nélkül feldolgoz. A második alapelv a frissesség elve. Annak érdekében, hogy egy lehallgatott üzenetet ne lehessen visszajátszani többször a címzett felé, az üzenetek frissességét ellenőrizni kell. Erre egy bevált módszer, hogy időbélyeggel látják el a hálózati csomagokat. Azaz a feladás időpontját rögzítik bennük és ez alapján, a másik oldalon a régi időbélyeggel rendelkező csomagokat ki lehet szűrni. 4.3 Szimmetrikus kulcsú algoritmusok A szimmetrikus kulcsú titkosítási eljárások nevüket onnan kapták, hogy a kódoló és dekódoló oldal is ugyanazzal a kulccsal dolgozik. A megoldások a helyettesítés és keverés módszereit használják, de az előtérbe a felhasznált algoritmusok bonyolultsága kerül. A szimmetrikus kulcsú titkosítók lehetnek blokk-kódolók. A blokk-kódolók a nyílt szöveget n- bites blokkokban kapják, majd ezeket a rendelkezésre álló kulccsal, a kódoló által használt algoritmussal kódolják. A módszer előnye, hogy egy blokk sérülése vagy elvesztése nem vonja maga után a teljes kódolt szöveg újrakódolását és hálózaton való újraküldését, hanem elegendő a hiányzó blokkot pótolni, mivel a blokkok függetlenek egymástól.

42 DES: A DES Data Encryption Standard kódolási eljárást az IBM fejlesztette ki, majd az amerikai kormányzat 1977-ben szabványosította. Mára elavult, de módosított változata használható. Blokk kódoló, a nyílt szöveget 64 bites egységekre bonja, majd ezeket egy 56 bites kulcs segítségével, 64 bites kódolt szövegekké alakítja. Az eljárás 19 lépcsőből áll. (4.2. ábra) 4.2. ábra: a DES adattitkosítási szabvány [12] alapján Az első lépésben, az aktuális 64 bites blokkon egy kulcs független keverést hajt végre. Az utolsó lépés az első lépés inverze, miután az utolsó előtt lépésben a 64 bites blokk első és második 32 bites részét cseréli fel. A köztes 16 lépés a kulcs felhasználásával módosítja a kódolandó szöveget. A módszer szimmetrikus kulcsú algoritmus, a dekódolás a kódoláshoz használt kulccsal történik, a lépések fordított sorrendben történő alkalmazásával. Az ábra (b) része egy közbenső lépést ábrázol. Egy közbenső lépés a 64 bites blokk első és második 32 bites részét két újabb 32 bites részre transzformálja. A bal oldali kimenet, a jobb oldali bemenet másolata, azaz változtatás nélküli másolata. A másik oldali kimenetet a bal és jobb oldali bemenet és a kulcsnak egy függvény segítségével előállított változatán végrehajtott kizáró vagy művelet eredménye képzi. Az algoritmus bonyolultságát a kulcson alkalmazott függvény adja, mely négy lépésen keresztül transzformálja azt. Az első lépésben a 32 bites részből egy 48 bites egységet képez jobb oldali kiterjesztéssel rögzített keverés, és másolás

43 35 segítségével, ennek jele E. Ezután az E és a kulcs között kizáró vagy műveletet végez. A következő lépésben az eredményt 8 db 6 bites csoportra osztja és ezeket S dobozon engedi át. Az S doboz ezekből 4 bites kimenetet képez. Végül a 8x4 bitet P dobozon futtatja végig. A DES kódoló a 16 közbenső lépésben a kulcs különböző, lépés specifikus változatait használja, melyeket transzformációs függvénnyel állít elő. Először 56 bites keverést alkalmaz, melynek eredményét két 28 bites részre vágja ketté. A kapott két bitmintát az iteráció sorszámával megegyező számmal balra forgatja. Végül 56 bites keverést végez, minek eredményének 48 bites részét permutálja AES: Az AES Advanced Encryption Standard az amerikai Nemzeti szabványügyi és Technológiai Intézet pályázatára készült titkosítási eljárás. A pályázat kiírásakor a következő feltételeket fogalmazták meg: szimmetrikus blokk kódoló teljesen nyilvános eljárás 128, 192, 256 bites kulcsokat is támogat hardveresen és szoftveresen is implementálható szabadon használható A pályázat nyertese Joan Deamon és Vincent Rijmen pályamunkája, mely a Rijndael nevet viselte novemberétől vált az amerikai kormányzat hivatalos szabványává, AES néven. Tulajdonságai: bites kulcsokat és blokkokat támogat, 32 bites lépésekben a kulcsok és blokkok hossza egymástól független az AES szabvány rögzíti a blokkméretet 128 bitre, a kulcs pedig 128, 192 vagy 256 bitesnek kell lennie A kódoló eljárás a helyettesítés és a keverés módszereit alkalmazza, matematikailag a Galois mezőkön alapul. 128 bites kulcs és blokk esetén 10 körben titkosít. (4.3. ábra)

44 ábra: az AES adattitkosítási szabvány [12] alapján Az eljárásnak három paramétere van: nyílt szöveg, titkosított szöveg és a kulcs. A nyílt szöveg és a titkosított szöveg száma egy egy 16 bájtos tömb áll rendelkezésre, a kulcs pedig 16 bájton tárolódik. A részeredményeket a state, azaz állapot tömb tárolja. A számítás kezdetén a program 11 tömbre, melyből az elsőt a számítás elején, a többit pedig a további tíz lépésben alkalmaz. A körök kulcsait forgatással és a kulcs különböző bitcsoportjainak kizáró vagy művelettel képzett eredményeivel állítja elő. A tíz kör mindegyike alatt változik az állapot tömb, mely változás négy lépésben történik Az első kör egy bájtról bájtra való helyettesítés. A második lépés a sorokat balra forgatja. A harmadik lépés az oszlopokat keveri össze egymástól függetlenül. Ezt mátrixszorzással végzi GF(2^8) Galois-mező segítségével. Az utolsó, azaz a negyedik lépésben alkalmazza az aktuális körhöz tartozó kulcsot, melyet kizáró vagy kapcsolatba hoz az állapot tömbbel. A dekódolás a lépések fordított irányú megismétlésével végezhető. 4.4 Döntés Az ismertetett kriptográfiai módszerek közül a XOR titkosítást választottam. Döntésem az indokolta, hogy minél egyszerűbb, kis számítási igényű, de biztonságos titkosítási eljárást szerettem volna alkalmazni. Kiválasztáskor szem előtt tartottam, hogy olyan fokú biztonsági megoldást használjak, mely arányban áll a védeni kívánt szellemi termék értékével, a megfejtéséhez szükséges energia legyen nagyobb, mint amit a titkosított információ ér és az esetleges feltörése hosszabb időt vegyen igénybe, mint amennyi idő két programkód frissítés között eltelik. A XOR titkosítási módszer megfelel ezeknek az elvárásoknak, mert az implementált programkódja kisméretű és az algoritmus, ami alapján dolgozik, kis komplexitású. Az eljárás egyetlen gyenge pontja, hogy a hálózaton küldött kulcs megszerezhető és ennek birtokában a titkosított üzenet könnyen visszafejthető. Ez azonban nem okozott gondot számomra, mivel a TFTP szervert futtató mikrokontrollerre

45 37 közvetlenül, a szerver feltöltésekor kerül fel a kulcs, így nincs szükség ennek a hálózaton történő továbbítására.

46 38 5 A hardver eszköz ismertetése A következőkben röviden ismertetem a hardver eszközt, melyet munkám során használtam. 5.1 ARM processzor Az ARM (Advanced RISC Machine) egy 32 bites, csökkentett utasítás készletű, módosított Harvard architektúra, melyet az ARM Limited fejleszt. Az általam használt mikrokontroller szívét képezi, a Cortex család M szériás tagjaként. (5.1. ábra) A Stellaris LM3S6965 mikrokontroller 36mA-t vesz fel átlagos felhasználás mellett, készenléti üzemmódban pedig mindössze 2uA-t óránként. [2] 5.1. ábra: a Cortex processzor teszteredménye más ARM processzorokhoz viszonyítva a frekvencia függvényében [2] 5.2 Stellaris 32-bit ARM Cortex M széria A 32 bites Stellaris ARM Coretx M szériát (5.2. ábra) a Texas Instruments Inc. forgalmazza. A mikrokontroller család komoly alkalmazások futtatását teszi lehetővé, alacsony fogyasztás mellett.

47 ábra: a Stellaris család block diagramja [13] 5.3 Texas Instruments Stellaris EKC-LM3S6965 Evaluation Kit [14] Feladatom elkészítéséhez Texas Instruments Stellaris EKC-LM3S6965 Ethernet Evaluation Kit-et (5.3. ábra) használtam. Ez egy kompakt, sokoldalú tesztpanel, melynek központi eleme a Stellaris LM3S6965 mikrokontroller. A következő perifériákat tartalmazza: - 10/100 Ethernet vezérlő - Alacsony fogyasztású in-circuit debug interfész - JTAG kompatibilis - USB csatlakozó - OLED grafikus kijelző - LED-ek, vezérlő gombok - Mikrofon - MicroSD kártya foglalat

48 ábra: Texas Instruments Stellaris EKC-LM3S6965 Evaluation Board [14] /100 Ethernet vezérlő: A mikrokontroller legfontosabb perifériája a teljesen integrált, Ethernet vezérlő (5.4. ábra), melyhez a tesztpanelon 10/100baseT RJ45 Ethernet csatlakozó aljzat található. [14] 5.4. ábra: 10/100 Ethernet vezérlő az Evaluation Board-on Az RJ45 csatlakozó két LED-et tartalmaz, melyek jelzik a forgalmat és a link státuszt. Ezeket a funkciókat a mikrokontroller hardveresen kezeli. Az MCU négy beépített oszcillátort tartalmaz, melyek közül a kicsi, 25MHz-es kristályt használja az Ethernet fizikai rétegének időzítésére, mely függetlenül működik a fő oszcillátortól.

49 41 6 Az lwip felhasználása, TFTP szerver megvalósítására Ebben a fejezetben bemutatom a TCP/IP megvalósítást, ami a munkám alapját képezte. Ismertetem, hogy a számos rendelkezésre álló implementáció közül miért erre esett a választásom. Leírom a tervezés folyamatát, megjelölöm azokat a különálló protokoll rétegeket, melyeket felhasználtam és egymáshoz illesztettem a kívánt cél eléréséhez. 6.1 Az lwip Az lwip a TCP/IP protokoll család egy megvalósítása, a Swedish Institute of Computer Science adta ki február 20-án. A fejlesztés alapvető célkitűzése volt, hogy kis kódméret mellett az alkalmazás, alacsony memória felhasználású legyen. [15] Az lwip megalkotását az egyre nagyobb számban terjedő, nagy teljesítményű mikrokontrollerek eredményezték, melyek észrevétlenül, az élet minden területén megjelentek. Alkalmazzuk őket az egészségügy, a biztonsági rendszerek, a szállítmányozás és a feldolgozó ipar területein. [15]Az implementáció nyílt forráskódú és ingyenesen felhasználható. Feladatom megvalósításához így különösen alkalmasnak találtam. 6.2 Felhasznált protokollok A következőkben ismertetem, hogy az lwip által kínált protokollok közül melyeket használtam fel és ezeket milyen módon illesztettem egymáshoz a kívánt működés eléréséhez. A TCP/IP protokollcsalád külön álló, egymással jól definiált kapcsolatban működő, rétegekből áll. A kiválasztott protokollokból tervezett szoftverrendszer részfeladatonként implementálható és egymástól függetlenül felhasználható egységeket képez. Az lwip szoftvercsomag számos protokoll megvalósítása közül ki kellett választanom és egymáshoz kellett illesztenem azokat, melyek szükségesek voltak a TFTP szerver működéséhez.

50 42 A Ethernet réteg megvalósítása nem része az lwip-nek. Az ehhez szükséges szoftverelemeket és drivereket a Texas Instruments által biztosított, StellarisWare szoftvercsomagból használtam fel. Az adatkapcsolati réteg fontos protokollja az ARP, mely elsődleges feladata, hogy felderítse annak az állomásnak az Ethernet címét, amerre csomagot kíván továbbítani az eszköz. A hálózati réteg megvalósításához az lwip Internet Protocol rétegét használtam, melyhez az ICMP protokollra is szükségem volt. Az ICMP az IP réteg viselkedését befolyásolja, hibaüzenetek és szolgálati üzenetek küldésével. Az eszköz DHCP protokoll segítségével kapja a kapcsolódó hálózatról az IP címét. Ha ez mégsem történik meg, akkor egy előre konfigurált címet oszt ki magának, amin elérhetővé válik. A szállítási réteg protokolljai közül az UDP-re volt szükségem. Végül a legfelső, az alkalmazási réteg következett, melybe az lwip TFTP megvalósítását illesztettem. Az alkalmazások az lwip szerint az apps mappában kell, hogy helyet foglaljanak. Ennek megfelelően készítettem egy könyvtárat, amit tftp szervernek neveztem el és ide illesztettem a TFTP kódját. Az így kapott szoftver belépési pontja az enet_lwip.c fájl, main függvényében található, ahol a vezérlés a SysCtlClockSet függvényre megy. Ez a függvény elvégzi a mikrokontroller működéséhez szükséges órajel beállítását. Tovább haladva inicializálom az UART-ot debug kimenetnek, majd az OLED kijelző készítem fel a futás során szükséges információk megjelenítésére a RIT128x96x4Init függvényen keresztül. Ezen a ponton elérkezem a hálózat kezelés alapvető lépéséhez, ahol a megtörténik az Ethernet vezérlő periféria aktivizálása a SysCtlPeripheralEnable(SYSCTL_PERIPH_ETH) függvénnyel. Ezután beállítom a systick-et periodikus interruptok-hoz, majd engedélyezem a processzoron végrehajtható megszakításokat illetve később az ehhez tartozó prioritási szinteket. Végül megtörténik az lwip-ből felhasznált protokollok inicializálása az lwipinit és a TFTP szerver elindítása a TFTPInit függvényeken keresztül. Miután minden szükséges függvény lefutott, a processzor végtelen, üres ciklus végrehajtásába kezd, amit a korábban engedélyezett interruptok szakíthatnak meg. 6.3 API [15] Feladataim között nem szerepelt, hogy egy új, általam megírt TFTP szerver kódot készítsek. Munkám során azonban felmerült ennek lehetősége, így megkezdtem az ezzel kapcsolatos előkészületeket. Az lwip TCP/IP megvalósítás rendelkezik API felülettel, melyen keresztül az alkalmazási réteg programkódjai kapcsolódhatnak az alattuk lévő réteg protokolljaihoz, ezzel

51 43 lehetőséget teremtve a TFTP protokoll illesztésére. A továbbiakban bemutatom az interfészt, majd ismertetem, hogy végül miért döntöttem úgy, hogy nem készítek el egy új TFTP protokollt megvalósító kódot. Az lwip TCP/IP stack-jének használatára két mód létezik: - TCP/UDP függvények közvetlen hívása - lwip API használata A következőkben ismertetem az API használat: A BSD TCP/IP implementáció magas szintű absztrakciós API-val rendelkezik. Az lwip a BSD megvalósításhoz képest, egy minimalista szemléletet követ, ami nem engedi meg ezt a szintet. Ennek ellenére az lwip API nagyon hasonlít a BSD interfészhez, annyi eltéréssel, hogy némileg alacsonyabb absztrakciós fokon működik. Az lwip API kifejezetten az lwip implementációhoz készült, felhasználva az lwip belső szerkezetének ismeretét, ezzel növelve a hatékonyságot. Nem követeli meg az adatok lemásolását az alkalmazás és a TCP/IP stack között, ezáltal a felső szinten lévő program közvetlenül képes manipulálni a belső puffereket, melynek eredményeképpen nő a hatékonyság és felére csökken a memória felhasználás. A BSD interfész elterjedtsége miatt rendelkezésre áll egy kompatibilitási réteg is, mely az lwip API-ra épül. Az lwip API a BSD megoldáshoz hasonlóan kapcsolat absztrakciót használ. Az adatok küldési mechanizmusa UDP és TCP esetben különbözik: TCP esetben az küldésre szánt adatokból csomag méretű darabokat képez, és listázza őket az átvitelhez. UDP esetben explicite lefoglal egy puffert, majd feltölti adattal. A TCP/IP stack azonnal elküldi a datagram-ot, amint a megfelelő függvény meghívásra kerül. Az API implementációja két részre bontható, a TCP/IP stack feldolgozási modellje alapján. (6.1. ábra) 6.1. ábra: az API implementáció részei [15]

52 44 A két részegység az úgynevezett Interprocess Communication (IPC) mechanizmuson keresztül kommunikál egymással. Az IPC mechanizmusok: - osztott memória - üzenet továbbítás - szemaforok Ha az lwip alatt futó operációs rendszer ezeket nem támogatja natív módon, akkor az operációs rendszer emulációs réteg képes emulálni őket. Az API alapvető tervezési elgondolás az volt, hogy a lehető legtöbb munkát az alkalmazási réteg végezze el. Ez azért fontos, mert a TCP/IP folyamatot egyszerre több alkalmazás is igénybe veheti Adattípusok: Az lwip API két adattípussal rendelkezik. - netbuf: a hálózati puffer absztrakciója - netconn: a hálózati kapcsolat absztrakciója Mindkét adattípus pointerként reprezentálódik, mely egy C struktúrára mutat. Az API-n keresztül megírt alkalmazásokhoz nincs szükség a struktúra belső felépítésének ismeretére. Helyette az API gondoskodik olyan függvényekről, melyek segítségével módosítani és olvasni lehet a szükséges mezőket Netbuf: A netbuf egy olyan puffer, ami adatok küldésére és fogadására alkalmas. Belsőleg pbuf-al társított. A netbuf, ahogy a pbuf is, képes hozzáférni mind a lefoglalt, mint a referencia által hivatkozott memóriához. A lefoglalt memória RAM, mely explicite van lefoglalva a hálózati adatoknak, míg a hivatkozott memória lehet az alkalmazás által kezelt RAM vagy külső ROM. A hivatkozott memória hasznos, ha olyan adatokat akarunk küldeni, melyet nem

53 45 módosítunk, mint például statikus weboldalak, vagy képek. A Netbuf-ban tárolt adatokat különböző méretű blokkokra lehet osztani. Ez azt jelenti, hogy az alkalmazásnak képesnek kell lenni fragmentált adat fogadására. A Netbuf egy pointerrel rendelkezik, a Netbuf-ban lévő fragemtumok egyikére. Két függvény, a netbuf_next() és a netbuf_first() alkalmas arra, hogy változtassuk ezt a mutatót. Azok a Netbuf-ok, amelyeket a hálózatról fogadunk, tartalmazzák továbbá a küldő IP címét és a portszámát. Ezek kinyerésére megfelelő függvények állnak rendelkezésre Konklúzió Egy, az API-n keresztül megvalósított TFTP szerver kevésbé hatékony működésű, mint az, ami közvetlenül az UDP réteg függvényeit hívja. Az általam választott, és beépített megvalósítás ilyen módon működik, ezért a mérnöki elveket szem előtt tartva elvetettem az API-t felhasználó, saját TFTP kód készítését, mert nem jelentett volna előrelépést a felhasznált megoldáshoz képest.

54 46 7 A CooCox rendszer alkalmazása Feladatom a Pázmány Péter Katolikus Egyetem Információs Technológiai Karán futó Elektromos Izomstimulátor projekt részeként került kiírásra. Az általam implementált TFTP szerver a tervek szerint egy operációs rendszer fölött fog működni egy HTTP szerverrel párhuzamosan, melyet Göndöcz Mátyás hallgatótársam készített el. A két alkalmazás a hálózatra kapcsolt, izomstimulátort működtető mikrokontrolleren futva nyújt majd hálózati szolgáltatásokat. A TFTP szerver az izomstimulátor távoli szoftveres frissítésére és konfigurálására, a HTTP szerver pedig a hálózaton keresztüli vezérlésére, a kezelések paramétereinek beállítására ad lehetőséget. A projekten dolgozó kollégáimmal és konzulensemmel egyetértésben választottuk ki a szükséges operációs rendszert, melyet a következőkben röviden ismertetek. Az operációs rendszer egy fejlesztőkörnyezet része, mely minden szükséges eszközt tartalmaz egy ARM Cortex M3-as processzorra történő fejlesztés támogatására. 7.1 A CooCox rendszer A CooCox - Cooperate on Cortex rendszer a kínai Wuhan University of Technology egyetem által fejlesztett, ARM Cortex M3 és M0 alapú mikrokontrollerek felhasználói szoftverfejlesztését támogató eszközcsalád. Tartalmaz egy integrált fejlesztőkörnyezetet (CoIDE), egy operációs rendszert (CoOS), egy JTAG-et használó hardver debug eszközt (Colink), egy FLASH memória programozó szoftvert (CoFlash), egy intelligens processzor láb konfiguráló alkalmazást és egy regiszter kezelő programot (CoAssistant). [16] 7.2 A CoOS operációs rendszer [17] A CoOS egy beágyazott, valós idejű multi-task operációs rendszer, ARM Cortex M3 szériás processzorokra tervezve, mely a CooCox rendszer része. Nyílt forráskódú és ingyenesen használható, így különösen előnyös az egyetemi fejlesztésben történő alkalmazása A CoOS tulajdonságai: - Ingyenes, nyílt forráskódú, valós idejű operációs rendszer

55 47 - Speciálisan Cortex-M szériás processzorokra tervezték - Skálázható, a minimális rendszer kernel csupán 974 Byte - Adaptálódó feladat ütemező algoritmus - Támogatja prioritásokat és a round-robint - A megszakítás késleltetése 0ms - Verem túlcsordulás érzékelés lehetősége - Semaphore, Mutex, Flag, Mailbox és Queue a kommunikációhoz és szinkronizáláshoz - Támogatja a következő platformokat: ICCARM, ARMCC, GCC Operációs rendszer alapú alkalmazásfejlesztés esetében, az alkalmazás gyakran számos feladatra bomlik. A CoOS-ben egy task egy C függvény, mely a belsejében egy végtelen ciklust tartalmaz. Továbbá paraméterezhető, és vannak visszatérési értékei. A task-ok állapotai a következők lehetnek: Ready State: Ready állapotban lévő task-ok azok, melyek végrehajthatóak, de az adott pillanatban nem futnak, mivel egy azonos, vagy egy magasabb prioritású task épp futási fázisban van. Minden task a létrehozása után ebbe az állapotba kerül. Running State: Egy task Running állapotú, amikor az adott pillanatban végrehajtás alatt van. Azaz a processzor erőforrást birtokolja. Waiting State: Waiting állapotról akkor beszélünk, amikor egy task vár egy eseményre, hogy bekövetkezzen, a CoOS rendszerben. The Dormant State: Dormant állapotba akkor kerülhet egy task, amikor törölték, és nem lehetséges az ütemezése. Ez nem azonos a Waiting állapottal, mivel a várakozó állapotban lévő feladat újraaktiválódhat és ütemezésre kerülhet, miután a várt esemény bekövetkezett. Tehát a Dormant állapotban lévő task-ok sohasem képesek újból aktiválódni. A task-ok állapotai a fent leírt négy eset között változhatnak. (7.1. ábra) Megfelelő függvényhívásokkal állapotátmenetek válthatók ki. (CoSuspendTask(): felfüggesztés, CoAwakeTask(): felébresztés)

56 ábra: a CoOS task-jainak állapotátmenet diagramja [16] 7.3 A CoIDE fejlesztőkörnyezet [16] A CooCox CoIDE egy magasan integrált szoftver fejlesztőkörnyezet ARM Cortex M3 és M0 alapú mikrokontrollerekhez. Biztosítja az összes olyan eszközt, mely szükséges magas minőségű szoftverek készítéséhez. A fejlesztők integrálták a fordítót és a debug eszközt is, hogy a használat a lehető legkényelmesebb legyen. Külön előnyt jelentett számomra, hogy a program Eclipse alapú, mivel korábbi, egyetemi tanulmányaimban már megismerkedtem ezzel a környezettel, Java programozás kapcsán. A StellarisWare szoftvercsomag - melyet a Texas Instruments az általam használt mikrokontrollerhez biztosít - könyvtárszintű példákat ad, ezzel szemben a CoIDE moduláris építkezést tesz lehetővé a már kész kódokból, melyeket a rendszer tartalmaz. (7.2. ábra)

57 ábra: a CoIDE modul kiválasztó felülete 7.4 Debug A CoIDE fejlesztőkörnyezet beépített debug eszközzel rendelkezik ábra: a CoIDE debug konfigurációs felülete Az első mezőben beállíthatjuk a hardver paramétereket. Az eszköz támogatja a Stellaris- ICDI-t. JTAG és soros vonali debug-olásra egyaránt lehetőségünk van. Az órajel frekvencia 2M és 100K között állítható. (7.3. ábra)

58 50 Három féle reset mode használata biztosított: - HW RESET - VECTRESET - SYSRESETREQ Ezek különböző debug indítási módokat jelentenek. Az első a hagyományos hardver reset, amikor az interrupt vektor az induláskor üres, és fel kell tölteni. A második esetben az IT vektor fel van töltve, indulásra kész, végül a harmadik esetben szintén az IT vektor táblából indul, de innen a vezérlés RAM területre megy és azt a kódot kezdi el futtatni, ami ott jelen van. A debug indulása tehát teljesen különbözni fog attól függően, hogy milyen módban indítom el. A debug elindítása után a környezet megváltozik. Új ablakok jelennek meg, melyek a következők: Disassembly view: Ebben az ablakban assembly utasítások formájában szemlélhető a futó kód, a forráskóddal vegyítve. Breakpoints view: Ez az ablak megjeleníti az össze breakpoint-ot, melyeket a programozó előzetesen beállított. Registers view: Itt információt kapunk a kiválasztott regiszterek értékeiről. Memory view: Ennek a nézetnek a segítségével monitorozhatjuk és változtathatjuk a végrehajtási memóriát. Négy különböző formátumban képes megjeleníteni a memória tartalmát: hexadecimális (alapértelmezett), ASCII, előjeles egész, előjel nélküli egész. Variables view: Ez az ablak a változók értékeiről ad információt. Expressions view: Az expression egy kódtöredék, mely kiértékelése után eredményt ad. Az expression környezete az aktuális debug modelltől függ. Debug view: A debug ablak a hibakeresés alatt álló kódról ad információt, fa hierarchiába rendezve. Periferials view: Ennek segítségével láthatjuk és megváltoztathatjuk a perifériális regiszterek értékeit.

59 51 8 Az lwip migrálása CoIDE fejlesztőkörnyezetre A TFTP szerver implementálását KEIL uvision fejlesztőkörnyezetben kezdtem el. Az elért eredményeimet, CoIDE fejlesztőkörnyezetre ültetnem át, mivel így válik elérhetővé a kívánt operációs rendszer támogatás. 8.1 A migrálás folyamatának leírása A munkát azzal kezdtem, hogy létrehoztam egy új projectet az CoIDE fejlesztőkörnyezetben, majd a moduláris építkezési lehetőséget kihasználva a Repository ablakban kiválasztottam a feladathoz szükséges modulokat (8.1. ábra): 8.1. ábra: kiválasztott CoIDE modulok a migráláshoz Ezután következett a project forráskódjának migrálása, melyet azzal kezdtem, hogy a főprogram fájlt, a fájlrendszert megvalósító kódot és az lwip konfigurációs header-jét elhelyeztem a project gyökérkönyvtárába.

60 52 A munka következő lépéseként lefordítottam az így kapott, még igen hiányos projectet. A vártnak megfelelően nagy mennyiségű hibaüzenetet kaptam. Ezek rendre annak voltak köszönhetők, hogy a projectből még hiányoztak a különböző funkciók header fájljai és a hozzájuk tartozó megvalósítások. Annak érdekében, hogy ezeket pótoljam, felépítettem egy függőségi fát, a megfelelő könyvtárrendszer kialakításán keresztül, melyet feltöltöttem a hiányzó header és forrásfájlokkal. Ezek után a fájlokban átírtam az #include hivatkozásokat a faszerkezetnek megfelelően. A munka eredményeként minden Fatal error típusú fordítási hibaüzenet eltűnt, és a fordítás a linkelési fázisba jutott és itt meg is állt. A következő eredményre jutotta: - disk_read - disk_write - disk_initialize - disk_status függvények Undefined reference errort adtak a ff.c fájlban. Ezt úgy oldottam meg, hogy kivettem az lmi-fs.c és az lmi-fsdata.h fájlokat a gyökérkönyvtárból. A project újrafordítása most már sikeres volt. A lefordított kódot fel lehetett tölteni a mikrokontoller memóriájába. A program láthatóan elindult az eszközön, ezt bizonyította, hogy a OLED kijelzőn megjelent az lwip beköszöntő üzenete. A következő lépés a futás során, hogy a mikrokontroller megvizsgálja, hogy van-e hálózati kapcsolat. Ha talál, akkor IP címet kér, ha nem, akkor egy alapértelmezett címet állít be maga számára. Ezt a képernyőn fel is tünteti. A várakozásokkal ellentétben, ez nem történt meg. Ezért valósidejű debug eljárást kellett alkalmazni, hogy felderítsem a hibát. Az operációs rendszer IT környezetébe illeszteni kellett az lwip lehetőséget! Feltételezhető volt, hogy az Interrupt-ok futása közben fellépő rendellenesség miatt állt meg a program futása. Nevezetesen, az első megszakítást követően, az Interrupt-ból képtelen visszatérni a vezérlés a főprogramba. A probléma gyökere: az Interrupt tábla üres. A program leállását az okozta, hogy a CooIDE startup kódjában más néven voltak deklarálva az interrupt függvények nevei, így a hívás következtében egy alapértelmezett interrupt kezelő kezdett el futni, mely egy végtelen ciklust tartalmaz. Tehát át kellett nevezni az interrupt függvényeket. Ezután a program megfelelően működött. A program systick alapú interrupt hívást is használ. Az új startup kód miatt ellenőriznem kellett, hogy a CoIDE-és és a uvision-ös projectben a számláló által kiváltott interrupt-ok frekvenciája egyezik-e. Ennek a legegyszerűbb módja, egy-egy LED-villogtató program

61 53 megírása a két környezetben. A státusz LED felvillanását a systick interrupt váltja ki peridikusan. Ezután egy oszcilloszkóppal, a LED lábáról kell mérést készíteni a program futása közben: 8.2. ábra: az interruptok frekvenciája KEIL uvisoon fejlesztőkörnyezetben 8.3. ábra: az interruptok frekvenciája CooCox CoIDE fejlesztőkörnyezetben Látható, hogy a két esetben a frekvencia egyezik, tehát a program működése megfelelő. (8.2. ábra) (8.3. ábra)

62 Interruptok [18] Az interrupt egy speciális eljáráshívás. Különlegességét az adja, hogy nem a futó kód érkezik el egy olyan kódrészlethez, mely egy függvényt hív, hanem egy külső eszköz állapotváltozása indukálja az állapothívást. A hívásból vissza kell tudni térni, és az interrupt által használt regiszterterületet el kell menteni, hogy miután véget ért az intermezzo, a kód futása zavartalanul folytatódhasson. Az interrupt-nak ezen kívül hardveres feltétele is van. Az interrupt hívása magával vonja a további interrupt-ok tiltását. (Ez egyfajta lock.) Ezért a hívás vége különbözik a függvények return visszatérésétől. A visszatérés ugyanis itt új interrupt-ot engedélyez. A Cortex-M3-as processzorok interrupt-okat és rendszer kivételeket támogatnak. A processzor és a Nested Vector Interrupt Controller (NVIC) prioritási sorrendet állít fel és kezeli az összes kivételt. Egy kivétel megváltoztatja a szoftver futás normális menetét. Az NVIC regiszterek vezérlik a megszakításkezelést. Hogy a rendszer megszakítások segítségével növelje a prioritáskezelést, az NVIC prioritási csoportokat támogat. Ez a csoportosítás alapvetően két részre osztja a beérkező megszakításokat: Felső mező: mely a csoportprioritást definiálja Alsó mező: mely egy alcsoportot definiál a csoporton belül Az NVIC tulajdonságai: - 38 interrupt típust támogat - 8 prioritási osztályt képes kezelni: 0-7, ahol a 0 a legmagasabb prioritás - kis késleltetéssel kezeli a az interrupt-okat és kivételeket - az interrupt jelek szint és impulzusészlelése - az interrupt-ok dinamikus újrapriorizálása - csoportosítja a különböző prioritású interrupt-okat a megfelelő csoportok és alcsoportokba - interrupt összefűzés - külső nem maszkolható interrupt A mikrokontroller automatikusan elhelyezi az aktuális állapotát egy veremben, ha egy kivétel érkezik, majd visszatölti onnan, amikor véget ér. Mindezt nagyon alacsony késleltetéssel, utasítás overhead nélkül végzi.

63 55 A processzor támogatja a level-sensitive és a pulse interrupt-okat. A level-sensitive interrupt addig tart, amíg a periféria megszünteti az interrupt jelet. Ez a gyakoribb eset. A pulse interrupt esetében a processzor órajelével szinkronban, minden felfutó él alatt egy mintavételezés történik. Annak érdekében, hogy az NVIC biztosan észlelje a megszakítási szándékot, a perifériának legalább egy teljes órajel ciklusig kell tartani az interrupt jelet. Amikor a processzor ISR (Interrupt Service Routine) állapotba lép, automatikusan megszűnik az interrupt-ra várakozó állapota. Az lwip esetében az Ethernet kontroller által kiváltott megszakítások fontos szerepet töltenek be. Ezek a következő esetekben jönnek létre: - Egy új Ethernet frame érkezik egy üres RX FIFO-ra - Egy Ethernet frame átvitele közben hiba lép fel - Egy Ethernet frame átvitele sikeresen megtörtént - RX FIFO túlcsordulás történt - Egy Ethernet frame hibásan érkezik meg - MII vezérlés sikeresen megtörtént a fizikai és a MAC réteg között - Egy vagy több fizikai rétegben fellépő feltétel adódik az alábbiak közül: - Az autonegotiation végbe ment - Távoli hiba - Megváltozott link státusz - Létrejövő kapcsolat - Párhuzamos hiba észlelés - Hibaüzenet fogadása - Jabber Event észlelése

64 56 9 TFTP szerver implementálása az alkalmazási rétegben A TFTP réteg megvalósítása a tftp.h és tftp.c fájlokban található. Hat függvényt tartalmaz melyek közül öt statikus és egy globálisan hívható. Statikus függvények: void TFTPErrorSend (unsigned long ulerror, char *pcerror) void TFTPDataSend(unsigned long ulblocknum) void TFTPDataAck(unsigned long ulblocknum) void TFTPDataRecv(void *arg, struct udp_pcb *upcb, struct pbuf *p,struct ip_addr *addr, u16_t port) void TFTPRecv(void *arg, struct udp_pcb *upcb, struct pbuf *p, struct ip_addr *addr, u16_t port) Globális függvény: void TFTPInit(void) A TFTP protokoll öt különböző típusú csomagot támogat, melyek operációs kódjai és a hozzájuk tartozó funkciók rendre: 1 TFTP_RRQ olvasási kérelem 2 TFTP_WRQ írási kérelem 3 TFTP_DATA az átvitt adat típusa 4 TFTP_ACK nyugta 5 TFTP_ERROR hibacsomag Az alkalmazás UDP protokollt használ csomagtovábbításra, melyhez a 69-es portot veszi igénybe. Minden UDP szakasz aktuális állapota az UDP protokollhoz tartozó PCB struktúrában tárolódik: struct udp_pcb { struct udp_pcb *next;

65 57 struct ip_addr local_ip, dest_ip; u16_t local_port, dest_port; u8_t flags; u16_t chksum_len; void (* recv)(void *arg, struct udp_pcb *pcb, struct pbuf *p); void *recv_arg; }; A TFTP hibakódjai a következők: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 definiálatlan hiba nincs meg a fájl hozzáférés megtagadva megtelt lemez nem megengedett művelet ismeretlen TID a fájl létezik nincs ilyen felhasználó 9.1 A függvények ismertetése: TFTPErrorSend: Három eset lehetséges, mely hibacsomag küldését eredményezi: - a szerver nem képes kielégíteni egy kérést - olyan csomag érkezik, mely nem fér bele a késleltetési időbe, vagy kétszer érkezik meg - megszakad a kapcsolat egy szükséges erőforrással Ez a függvény felel azért, hogy hiba esetén egy hibacsomag menjen a kliens felé. Mivel nem garantált, hogy ez megérkezik, választ nem vár. TFTPDataSend: A TFTP csomag küldéséért felelős. A csomagok 512 byte-os egységeket képeznek. A csomagküldés végét az utolsó, 512 bájtál kisebb csomag jelzi.

66 58 TFTPDataAck: A TFTP protokoll stop-and-wait elvet követ. Ez azt jelenti, hogy minden elküldött adatcsomag után nyugtát vár, és csak ezután küldi a következő csomagot. Ha a kliens adatot küld a szerver felé, a szerver ennek a függvénynek a segítségével nyugtázza a beérkező adatblokkokat. TFTPDataRecv: Ez a függvény felel azért, hogy a TFTP réteg alatt elhelyezkedő, UDP rétegtől kapott datagram-ok információi megfelelően legyenek feldolgozva. Felhasználja a korábban ismertetett függvényeket. Irányítja az adatátvitel TFTP rétegre eső feladatait. TFTPRecv: A bejövő TFTP kéréseket kezeli. Értelmezi őket aszerint, hogy PUT vagy GET kérés érkezett a kliens féltől. TFTPInit: Inicializálja a TFTP szervert. UDP socketet alakít ki, melyen a szerver a 69-es porton figyeli a bejövő kéréseket. Végül a szerver elindulását az OLED kijelzőn jelzi.

67 59 10 Titkosító program implementálásának ismertetése Az ismertetett titkosítási módszerek közül a XOR titkosítási eljárást megvalósító programokat készítettem el. Ebben a fejezetben leírom a titkosítást végző program működését, majd ez alapján ismertetem a dekódoló programot. A program a sztenderd I/O könyvtárat használja, ennek megfelelően az include hivatkozásoknál beemelem a kódba az ehhez tartozó header fájlt: stdio.h. Ezt követően három mutatót deklarálok a fájlkezeléshez. Az alkalmazás a kitűzött célhoz hűen egyszerű és rövid, mindössze egy main függvényből áll. A függvény elején három karakter típusú változót definiálok, melyekre a bitenkénti XOR művelet elvégzésénél lesz szükségem. A program a fájlkezelő résszel folytatódik. Itt megnyitásra kerül a titkosításra szánt állomány, a titkosításra használt kulcsfájl, illetve létrehozom a kimeneti fájlt. Hiba esetén a program abortál, de hibaüzenetet küld a felhasználónak. A következő lépésben egy ciklus segítségével elvégzi a bitenkénti kizáró vagy műveletet a két bemeneti állományon és az eredményt a kimeneti állományba írja. Végül lezárja a használt fájlokat és sikeres titkosítás esetén a siker tényét közli a felhasználóval. A dekódoló program nagyon hasonlít a fent leírt titkosító eljáráshoz. A különbség abban rejlik, hogy a kulcsfájl bitjeit rendre a dekódolt fájl bitjeivel hozom kizáró vagy kapcsolatba. Ennek eredményeként megkapom a kódoló program bemenetét képező állományt olvasható formában. (10.1. ábra) A dekódoló alkalmazás a mikrokontrolleren, a CoOS operációs rendszer felett futtatva, a TFTP szervertől függetlenül indítható.

68 10.1. ábra: a XOR titkosító program folyamatábrája 60

69 61 11 Tesztelési módszer ismertetése, eredmények értékelése Ebben a fejezetben ismertetem a tesztelési módszereket és értékelem a kapott eredményeket A TFTP szerver tesztelése A mikrokontroller memóriájába feltöltött UDP/IP stack-et, Wireshark protokoll elemző programmal teszteltem. A tesztkonfigurációt a következőképpen állítottam össze: egy Windows XP operációs rendszert futtató PC-hez, USB porton keresztül csatlakoztattam a Stellaris fejlesztőpanelt. A PC-t és a fejlesztőpanelt hálózati kábellel kötöttem egy routerhez, mely ADSL hálózathoz kapcsolódott. Ez követően megvártam, hogy a laptop és a mikrokontroller is megkapja DHCP protokoll segítségével az IP címét, melyek a következők voltak: PC: Stellaris: A Stellaris panel OLED kijelzőjén megjelent a kiosztott IP cím. Megállapítható, hogy az Ethernet vezérlő, az IP réteg és a DHCP protokoll működik az eszközön. Ezután, hogy ellenőrizzem az ICMP protokoll működését, a PC-n indított egy parancssor terminált, majd kiadtam a ping parancsot a mikrokontroller IP címére: ping Az adatforgalmat Wireshark-al figyeltem: ICMP kérés: ICMP 74 Echo (ping) request id=0x0200, seq=1536/6, ttl=64 ICMP válasz: ICMP 74 Echo (ping) reply id=0x0200, seq=1536/6, ttl=255 Az ICMP protokoll tehát működik. A tesztelés következő fázisában a PC parancssor termináljából, a C:\ gyökérből kiadtam a következő parancsot:

70 62 tftp put eeprom.c eeprom.c Ezzel a paranccsal egy TFTP klienst indítottam el, mely a Stellaris panelnek küldött egy írási kérelmet. Mivel a mikrokontroller IP címét a PC nem ismerte, így első lépésben egy ARP Broadcast kérést küldött a hálózatra azzal a céllal, hogy felderítse a címzett IP címéhez tartozó Ethernet címet AsustekC_8b:55:32 Broadcast ARP 42 Who has ? Tell Erre a kérésre a mikrokontroller válaszolt TexasIns_00:0e:4d AsustekC_8b:55:32 ARP is at 00:1a:b6:00:0e:4d A küldött ARP csomagban szerepelt az IP címéhez tartozó Ethernet címe: 00:1a:b6:00:0e:4d Látható, hogy az ARP protokoll működik az eszközön. Ezen a ponton minden feltétel adott volt, hogy megkezdődjön a TFTP protokoll működése. A PC egy TFTP kérést küldött a mikrokontrollernek fájl írásra netascii módban: TFTP 63 Write Request, File: eeprom.c, Transfer type: netascii A mikrokontroller válaszul nyugtát küldött, amivel jelezte, hogy kész a fájl fogadására, megkezdődhet a küldés: TFTP 60 Acknowledgement, Block: 0 A küldés megkezdődött: TFTP 55 Data Packet, Block: 1 (last) Majd az átvitt blokkra nyugta érkezett TFTP 60 Acknowledgement, Block: 1 Ezzel az átvitel befejeződött. A TFTP szerver az UDP protokoll felett működik.

71 A titkosító program tesztelése A titkosító programot UNIX operációs rendszer fölött teszteltem. Az alábbi egyszerű, C programozási nyelven írt kódot titkosítottam: #include inc/hw_ints.h int main(){ return 0; } A kulcs a következő karaktersor volt: lbkdlfkbojosvcxmbsfdkdsnvkndskvkvkdvmksdnvknajcbsa2 A titkosítást követően a következő eredményt kaptam: ábra: a titkosított c program Midnight Editorral megnyitva Végül a titkosított állományon lefuttattam a dekódoló programot, ami a következőt eredményezte: #include inc/hw_ints.h int main(){ return 0; } Megállapítottam, hogy a tesztelés az elvárásoknak megfelelő eredményt adta. A titkosítást követően a dekódoló program, a titkosított állományból a kulcs felhasználásával visszaállította az eredeti, titkosításra szánt állományt.