Hetedik előadás Blokktitkosítók működési módjai, folyamtitkosítók Kriptográfia Hetedik előadás Blokktitkosítók működési módjai, folyamtitkosítók Lecture slides by Lawrie Brown for “Cryptography and Network Security”, 4/e, by William Stallings, Chapter 1 “Introduction”. Dr. Németh L. Zoltán SZTE, Számítástudomány Alapjai Tanszék 2012 tavasz

Blokktitkosítók működési módjai a blokktitkosítók rögzített méretű adatmennyiséget (egy blokkot) titkosítanak egyszerre pl. a DES 64 bitet, az AES 128 bitet valamilyen úton tetszőleges mennyiségű adata titkosítása/megfejtése kell a gyakorlatban 1983: a NIST 4 működési módot (Modes of Operations) vezetett be: FIPS 81-es szabvány később egy ötödik módot is definiáltak ezek közt mind blokk mind folyam módok vannak egymástól hatékonyságukban, biztonságukban, illetve hiba tűrésükben különböznek egy tetszőleges blokktitkosítóval való titkosítás lehetséges útjait igyekeznek lefedni melyekből az alkalmazás követelményekhez választhatunk DES (or any block cipher) forms a basic building block, which en/decrypts a fixed sized block of data. However to use these in practise, we usually need to handle arbitrary amounts of data, which may be available in advance (in which case a block mode is appropriate), and may only be available a bit/byte at a time (in which case a stream mode is used). To apply a block cipher in a variety of applications, four “modes of operation” have been defined by NIST (FIPS 81). The four modes are intended to cover virtually all the possible applications of encryption for which a block cipher could be used. As new applications and requirements have appeared, NIST has expanded the list of recommended modes to five in Special Publication 800-38A. These modes are intended for use with any symmetric block cipher, including triple DES and AES.

Elektronikus kódkönyv mód Electronic Codebook Book (ECB) a lehető legegyszerűbb alkalmazás az üzenetet először blokkméret méretű blokkokra tördeljük, majd azokat titkosítjuk minden blokk értékét a titkosítás szerinti értékkel helyettesítjük, mintha egy gigantikus méretű kódkönyvet használnánk minden blokk a többi blokktól függetlenül kerül titkosításra, pl: Ci = DESK(Pi) a példákban a DES-t használjuk, de vehetnénk más blokktitkosítót is használata: egyetlen titkos érték átvitelére The simplest mode is the electronic codebook (ECB) mode, in which plaintext is handled one block at a time and each block of plaintext is encrypted using the same key. ECB is the simplest of the modes, and is used when only a single block of info needs to be sent (eg. a session key encrypted using a master key).

Elektronikus kódkönyv mód (ECB) Stallings Figure 6.3 illustrates the Electronic Codebook (ECB) Mode.

Az ECB hátrányai azért gyenge, mert a blokkok egymástól függetlenül kódolódnak a nyílt szöveg azonos blokkjai azonosak lesznek így a nyílt szöveg ismétlődő blokkjai ismétlődnek a titkosított szövegben is ha az üzenet erősen strukturált, ez kihasználható a támadó beszúrhat/helyettesíthet/átrendezhet blokkokat ha az üzenet csak kis mértékben változik (pl. egy szerződésben csak az összeg) táblázat készíthető hozzá csak akkor használható, ha csak néhány blokkot kell titkosítani, pl. egy kulcsot ECB is not appropriate for any quantity of data, since repetitions can be seen, esp. with graphics, and because the blocks can be shuffled/inserted without affecting the en/decryption of each block. Its main use is to send one or a very few blocks, eg a session encryption key.

Rejtjeles blokkok láncolása Cipher Block Chaining (CBC) az aktuális blokk titkosításának eredményét felhasználja a következő blokk titkosításához is a nyílt szöveg és az előző rejtjeles blokk között egy XOR műveletet végzünk titkosítás előtt így két egyforma blokk nem ugyanúgy fog titkosítódni, mert az előző blokk más sőt, az aktuális blokk titkosítása függ minden előző blokk értékétől egy kezdő vektor (Initial Vector, IV)-vel kezdünk: C0 = IV (rögzített, vagy mellékelve elküldött érték) Ci = DESK(Pi XOR Ci-1), i=1, 2, … használata: sok adat titkosítása, ha az összes adat előre rendelkezésre áll (pl. e-mail, FTP, web) To overcome the problems of repetitions and order independence in ECB, want some way of making the ciphertext dependent on all blocks before it. This is what CBC gives us, by combining the previous ciphertext block with the current message block before encrypting. To start the process, use an Initial Value (IV), which is usually well known (often all 0's), or otherwise is sent, ECB encrypted, just before starting CBC use. CBC mode is applicable whenever large amounts of data need to be sent securely, provided that all data is available in advance (eg email, FTP, web etc).

Cipher Block Chaining (CBC) Stallings Figure 6.4 illustrates the Cipher Block Chaining (CBC) Mode.

Üzenet helykitöltése (Message Padding) az üzenet végén lehet, hogy egy blokkhossznál rövidebb rész marad amit kezelni kell az üzenetet fel kell tölteni (ki kell egészíteni), hogy egész számú blokk legyen a helyet kitölthetjük ismert nem adat értékekkel pl. 0-kkal vagy a feltöltés hosszát beírhatjuk az utolsó bájtba pl. [ b1 b2 b3 0 0 0 0 5] azt jelenti, hogy 3 bájt adatbájt és 5 bájt a feltöltés esetenként szükségünk lehet, még egy extra blokk használatára, hogy mindig legyen feltöltés és így a visszaalakítás egyértelmű legyen vannak bonyolultabb technikák, melyekkel ez elkerülhető One issue that arises with block modes is how to handle the last block, which may well not be complete. In general have to pad this block (typically with 0's), and then must recognise padding at other end - may be obvious (eg in text the 0 value should usually not occur), or otherwise must explicitly have the last byte as a count of how much padding was used (including the count). Note that if this is done, if the last block IS an even multiple of 8 bytes or has exactly the same form as pad+count, then will have to add an extra block, all padding so as to have a count in the last byte. There are other, more esoteric, “ciphertext stealing” modes, which avoid the need for an extra block.

A CBC előnyei és korlátai általánosan használt mód a titkosított blokk minden előtte levő blokktól függ egy blokk egyetlen blitjének megváltozása a az összes további blokk titkosítását teljesen megváltoztatja (lavinahatás) a titkosítás nem, de a megfejtés párhuzamosítható kezdővektor kell (IV), melyet ismernie kell a küldőnek és a címzettnek de nem küldhető el titkosítás nélkül, mert a támadó azt meghamisítva a nyílt szöveg első blokkjának tetsző-leges bitjeit invertálni tudja (akármit hamisíthat oda) ezért IV vagy előre rögzített érték legyen vagy ECB módban titkosítva küldjük el előre CBC is the block mode generally used. The chaining provides an avalanche effect, which means the encrypted message cannot be changed or rearranged without totally destroying the subsequent data. However there is the issue of ensuring that the IV is either fixed or sent encrypted in ECB mode to stop attacks on 1st block.

A titkos szöveg visszacsatolása Cipher FeedBack (CFB) ha az adatfolyam csak időnként bitekből/bájtokból áll (mint például egy terminál-hoszt kapcsolat) más titkosítási módszer kell, mert nem tarthatjuk vissza az információt a visszacsatolás általában a blokkméretnél kisebb mondjuk s bites egységekben történik (pl. s=8 bit) azaz s bitet titkosít egyszerre (= folyam mód) a kulcsot csak közvetve használjuk a titkosításhoz s álvéletlen bitet generálva, melyekkel XOR-olva titkosítunk az eredményt visszacsatoljuk a következő s álvéletlen bit előállításához a szabványokban s értéke: 1,8, 64 vagy 128 jelölése: CFB-1, CFB-8, CFB-64, CFB-128 stb. ha s = blokkhossz, akkor C0 = IV Ci = Pi XOR DESK(Ci-1) használata: általános célú adatfolyamok tikosítása, hitelesítés If the data is only available a bit/byte at a time (eg. terminal session, sensor value etc), then must use some other approach to encrypting it, so as not to delay the info. Idea here is to use the block cipher essentially as a pseudo-random number generator (see stream cipher lecture later) and to combine these "random" bits with the message. Note as mentioned before, XOR is an easily inverted operator (just XOR with same thing again to undo). Again start with an IV to get things going, then use the ciphertext as the next input. As originally defined, idea was to "consume" as much of the "random" output as needed for each message unit (bit/byte) before "bumping" bits out of the buffer and re-encrypting. This is wasteful though, and slows the encryption down as more encryptions are needed. An alternate way to think of it is to generate a block of "random" bits, consume them as message bits/bytes arrive, and when they're used up, only then feed a full block of ciphertext back. This is CFB-64 or CFB-128 mode (depending on the block size of the cipher used eg DES or AES respectively). CFB is the usual choice for quantities of stream oriented data, and for authentication use.

Cipher FeedBack (CFB) Stallings Figure 6.5 illustrates the Cipher FeedBack (CFB) Mode.

A CFB előnyei és korlátai legelterjetebb mód, amivel blokktitkosítót folyamtitkosítóként alkalmazhatunk csak a titkosító algoritmust használja a megfejtőt nem, így csak szimmetrikus kulcsú módszerekkel használható (nyilvános kulcsúakkal nem !) lassabb adatmozgást biztosít, mint maga a titkosító algoritmus blokkhossz/s menet kell egy blokknyi adat titkosításához érzékenyebb az adatátviteli hibákra egy bithiba az egész következő blokkot olvashatatlanná teszi (a lavinahatás miatt), és még további blokkokat is de miután a hibás bit a shift regiszterből kilép visszaáll a rend => önszinkronizáló (self syncronizing) mód persze ez elkerülhető megbízható adatátviteli réteg használatával, különben az OFB mód helyettesítheti CFB is the usual stream mode. As long as can keep up with the input, doing encryptions every 8 bytes. A possible problem is that if its used over a "noisy" link, then any corrupted bit will destroy values in the current and next blocks (since the current block feeds as input to create the random bits for the next). So either must use over a reliable network transport layer (pretty usual) or use OFB.

A kimenet visszacsatolása Output FeedBack (OFB) az üzenetet szintén folyamként dolgozza fel de most a titkosító algoritmus kimenetét, és nem magát a titkosított szöveget csatoljuk vissza így a generált álvéletlen bitek függetlenek a nyílt szövegtől, előre kiszámíthatók ha s = blokkhossz O0 = IV Oi = DESK(Oi-1) Ci = Pi XOR Oi használata: folyamtitkosítás zajos csatornán át The alternative to CFB is OFB. Here the generation of the "random" bits is independent of the message being encrypted. The advantage is that firstly, they can be computed in advance, good for bursty traffic, and secondly, any bit error only affects a single bit. Thus this is good for noisy links (eg satellite TV transmissions etc).

Output FeedBack (OFB) Stallings Figure 6.6 illustrates the Output FeedBack (OFB) Mode.

Az OFB előnyei és korlátai itt is blokkhossz/s menet kell egy blokknyi adat titkosításához, de az álvéletlen bitek előre kiszámíthatók, ha biztonságosan tudjuk tárolni amint az adat megvan mehet a titkosítás a bithibák nem terjednek szét, csak egy bit lesz rossz a blokkszinkron hibák viszont nem javíthatók, ha egy Ci elvész, ami utána jön megfejthetetlen -> szinkronizálás kell igazából a Vernam-titkosító egy variációja így tilos ugyanazt a kulcsot és IV-t többször használni sérülékenyebb az üzenetcsatorna módosításaival szemben bebizonyították, hogy csak s = blokkméret választással lehet biztonságos (pl 3DES-OFB-64 or AES-OFB-128) mindkét oldalon visszacsatolás van => nem párhuzamosítható One advantage of the OFB method is that bit errors in transmission do not propagate. The disadvantage of OFB is that it is more vulnerable to a message stream modification attack than is CFB. Since OFB is a Vernam cipher variant, the stream should never be used more than once (otherwise the 2 ciphertexts can be combined, cancelling these bits, and leaving a "book" cipher to solve). And sender & receiver need to remain in sync, or all data is lost. Also, research has shown that you should only ever use a full block feedback ie OFB-64/128 mode.

Számláló mód Counter (CTR) ez egy “új” (ötödik) mód, bár már elég régen javasolták (1979) hasonlít az OFB módhoz, de egy számláló értékét titkosítja, nem pedig visszacsatolt értéket minden blokkhoz különböző értékpár kulcs & számláló kell (tilos újra használni) Oi = DESK(i) Ci = Pi XOR Oi használata: nagy sebességű hálózati titkosításnál, aszinkron adatátviteki mód, IPSec egy blokkhossz méretű számlálót használ, melynek értékei minden nyílt szövegek blokktól különbözők legyenek a számláló tipikusan egy kezdeti véletlen érték, amit egyesével növelünk The Counter (CTR) mode is a variant of OFB, but which encrypts a counter value (hence name). Although it was proposed many years before, it has only recently been standardized for use with AES along with the other existing 4 modes. It is being used with applications in ATM (asynchronous transfer mode) network security and IPSec (IP security). A counter, equal to the plaintext block size is used. The only requirement stated in SP 800-38A is that the counter value must be different for each plaintext block that is encrypted. Typically the counter is initialized to some value and then incremented by 1 for each subsequent block.

Counter (CTR) Stallings Figure 6.7 illustrates the Counter (CTR) Mode.

A CTR előnyei és korlátai egyszerűség: csak a titkosító algoritmust kell hozzá implementálni hatékonyság párhuzamosítható mind h/w mind s/w szinten előre generálható a ,,kulcsfolyam’’ alkalmas sok adat gyors titkosításához közvetlenül is hozzáférhetünk az adatblokkokhoz (random access) bizonyíthatóan legalább olyan biztonságos mint a többi mód de biztosítani kell, hogy ugyanazt a kulcs-számláló párt sohase használjuk újra, különben feltörhető. CTR mode has a number of advantages in parallel h/w & s/w efficiency, can preprocess the output values in advance of needing to encrypt, can get random access to encrypted data blocks, and is simple. But like OFB have issue of not reusing the same key+counter value.

Folyamtitkosítók (Stream Chiphers) az üzenetet bitenként (bájtonként) dolgozza fel adatfolyamként ehhez a kulcsból egy álvéletlen (pseudo random) kulcsfolyamot (keystream) állít elő majd XOR műveletet végez vele bitenként mint a OTP, csak ott valódi és nem álvéletlen a kulcsfolyam a kulcsfolyam véletlensége teljesen megsemmisíti a nyílt szöveg statisztikai jellemzőit Ci = Mi XOR StreamKeyi de ugyanazt a kulcsot tilos többször alkalmazni, különben feltörhető (nem úgy mint a blokktitkosítóknál.) A typical stream cipher encrypts plaintext one byte (or bit) at a time, usually by XOR’ing with a pseudo-random keystream. The stream cipher is similar to the one-time pad discussed in Chapter 2. The difference is that a one-time pad uses a genuine random number stream, whereas a stream cipher uses a pseudorandom number stream. But rely on the randomness of stream key completely destroys statistically properties in message. However, you must never reuse a stream key since otherwise you can recover messages (as with a book cipher).

A folyamtitkosítók általános felépítése Stallings Figure 6.8 illustrates the general structure of a stream cipher, where a key is input to a pseudorandom bit generator that produces an apparently random keystream of bits, and which are XOR’d with message to encrypt it, and XOR’d again to decrypt it by the receiver.

A folyamtitkosítók tulajdonságai néhány tervezési elv: a kulcsfolyam hosszú periódusú legyen hosszabb ismétlődések nélkül állja ki a véletlenség statisztikai próbáit ekkor a rejtjelezett szöveg is véletlennek látszó lesz egy elég hosszú kulcstól függjön (pl. ma >= 128 bit) magas lineáris kompexitású legyen az alkalmasan tervezett folyamtitkosító ugyanolyan biztonságos lehet, mint az azonos kulcshosszú blokktitkosító (csak brute force) de általában egyszerűbb (pár soros kód!) és gyorsabb [KUMA97] lists the following important design considerations for a stream cipher: The encryption sequence should have a large period, the longer the period of repeat the more difficult it will be to do cryptanalysis. The keystream should approximate the properties of a true random number stream as close as possible, the more random-appearing the keystream is, the more randomized the ciphertext is, making cryptanalysis more difficult. To guard against brute-force attacks, the key needs to be sufficiently long. The same considerations as apply for block ciphers are valid here .Thus, with current technology, a key length of at least 128 bits is desirable. With a properly designed pseudorandom number generator, a stream cipher can be as secure as block cipher of comparable key length. The primary advantage of a stream cipher is that stream ciphers are almost always faster and use far less code than do block ciphers.

Az RC4 tervezte Ron Rivest (RSA Security, 1987) az RSA üzleti titokként kezelte a kódját, de valaki elküldte a Cypherpunks lev. listára 1994-ben nagyon egyszerű, így rendkívül hatékony változtatható kulcsméretű, bájtonként dolgozik az egyik legelterjedtebb (SSL/TLS, WPA, WEP) folyamtitkosító a kulcsfolyamhoz a 0..255 számok (ál)véletlen permutációit használja a kulcsból előállít egy álvéletlen permutációt, majd az aktuális, permutáción kever még egyetet, majd generál belőle egy bájtot, amivel XOR-olva titkosítja az aktuális bájtot RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security. It is a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. Analysis shows that the period of the cipher is overwhelmingly likely to be greater than 10^100. Eight to sixteen machine operations are required per output byte, and the cipher can be expected to run very quickly in software. RC4 is probably the most widely used stream cipher. It is used in the SSL/TLS secure web protocol, & in the WEP & WPA wireless LAN security protocols. RC4 was kept as a trade secret by RSA Security, but in September 1994 was anonymously posted on the Internet on the Cypherpunks anonymous remailers list. In brief, the RC4 key is ued to form a random permutation of all 8-bit values, it then uses that permutation to scramble input info processed a byte at a time.

RC4 előkészítési fázis kiindulás: S tömb a 0..255 számokkal melyet a kulcs alapján megkeverünk keylen a kulcs mérete bájrtokban (max 256 bájt = 2048 bit) S adja majd meg a titkosító belső állapotát for i = 0 to 255 do S[i] = i T[i] = K[i mod keylen]) j = 0 j = (j + S[i] + T[i]) (mod 256) swap (S[i], S[j]) // csere keylen a kulcs mérete bájrtokban (max 256) K[i] a kulcs i. bájtja Eredmény a kulcs segítségével megkevert S tömb Az S-beli 256 szám 256! féle lehetséges permutációja jóval több, mint amiket egy 2048 bites kulccsal ki tudunk jelölni de nincs értelme a kulcs méretét tovább növelni The RC4 key schedule initialises the state S to the numbers 0..255, and then walks through each entry in turn, using its current value plus the next byte of key to pick another entry in the array, and swaps their values over. After doing this 256 times, the result is a well and truly shuffled array. The total number of possible states is 256! - a truly enormous number, much larger even than the 2048-bit (256*8) max key allowed can select.

RC4 titkosítás a titkosítás/megfejtés (ugyanaz a kulcsfolyam kell!) során tovább keverjük az aktuális permutációt a megcserélt pár értékeinek összege (t) jelöli ki az aktuális „kulcs bájtot” (S[t] -t) a táblázatból ami az üzenet következő bájtjával XOR-olva adja a titkosítást/megfejtést i = j = 0 for each message byte Mi i = (i + 1) (mod 256) j = (j + S[i]) (mod 256) swap(S[i], S[j]) t = (S[i] + S[j]) (mod 256) Ci = Mi XOR S[t] To form the stream key for en/decryption (which are identical), RC4 continues to shuffle the permutation array S by continuing to swap each element in turn with some other entry, and using the sum of these two entry values to select another value from the permutation to use as the stream key, which is then XOR’d with the current message byte.

RC4 áttekintés Stallings Figure 6.9 illustrates the general structure of RC4.

Az RC4 biztonsága az eddigi kutatások alapján biztonságos az ismert támadásfajtákkal szemben (persze elég hosszú kulcs esetén, >= 128 bit) van néhány gyakorlatban kivitelezhetetlen kriptoanalízisen alapuló támadás nagyon nem lineáris titkosító mivel RC4 folyamtitkosító, ezért tilos a kulcsot újra felhasználni ezzel van a fő probléma a WEP esetén, de ezt sérülékenységet a kulcsgenerálás gyengesége okozza és nem magát az RC4-et érinti A number of papers have been published analyzing methods of attacking RC4, but none of these approaches is practical against RC4 with a reasonable key length, such as 128 bits. A more serious problem occurs in its use in the WEP protocol, not with RC4 itself but the way in which keys are generated for use as input to RC4. Currently RC4 its regarded as quite secure, if used correctly, with a sufficiently large key.

Felhasznált irodalom Virrasztó Tamás: Titkosítás és adatrejtés: Biztonságos kommunikáció és algoritmikus adatvédelem, NetAcademia Kft., Budapest, 2004. Online elérhető: http://www.netacademia.net/book.aspx?id=1# William Stallings: Cryptography and Network Security, 4th Edition, Prentice Hall, 2006. (Chapter 6) Lawrie Brown előadás fóliái (Chapter 6)