Emlékeztető létrehozásához biztonságos kommunikációs csatorna programozó jegyzetek
1. Nyilatkozat a probléma
Vannak felhasználók az A és B, amely üzeneteket váltani. Tudják használni a TCP, UDP, e-mail vagy a chat - most már nem számít. Vannak E támadó elfoghatja, cseréje átrendezni ezeket az üzeneteket, hogy azok eltűnnek nyom nélkül, és küldje nevében üzeneteket az A és B A feladat -, hogy segítsen az A és B csere üzeneteket oly módon, hogy az E Nem találtunk azok tartalmát. Megszabadulni E nem lehet.
2. Data Encryption
Mint egy titkosítási algoritmus Schneier és Ferguson javasoljuk AES (Rijndael 128 bites blokk) a kulcs hossza 256 bit mód CTR. Ebben az üzemmódban a maximális mérete az üzenet 16 · 2 32 bájt. Nem valószínű, hogy valaki veszélyben ezt a korlátozást. Szélsőséges esetben, akkor lehet osztani egy üzenetet részekre.
Titkosítani egy üzenetet szám i, amelyek mérete L bit, L bit kell számítani a következő módon:
ahol EK funkció (128 bites kimenet) - titkosítási algoritmus, a K (256 bit) - titkosítási kulcsot érv a funkció (128 bit) - titkosított adatokat, és a || Ez azt jelenti, összefűzése adatokat. Kiszámítása után a biteket b1 ... bL add őket Zhegalkin (kizárólagos OR, XOR művelet ⊕) bit az üzenet, az eredmény rejtjelezett. Dekódolni kell tennie pontosan ugyanabban a sorrendben műveletek felett rejtjelezett.
Fontos figyelni a két pontot. Először is, a titkosítási kulcsok adatküldés A-ból B és B-A különbözőnek kell lennie. Másodszor, meg kell megegyezni a bájtsorozatok az érv EK funkciót. A byte sorrendben 32 bites számok eltérőek lehetnek attól függően, hogy a CPU architektúra. Hagyományosan, a hálózati protokollok és formátumok által használt byte sorrendben a legrégebbi a legfiatalabb.
3. hash függvény
Mondjuk, már sikeresen létrehozott egy session kulcsot a DiffieHellman-algoritmus. eredményeként az A és B kap egy közös K kulcs Ezután a következő eseménysor:
// Megszabadulni kulcs algebrai struktúra
K = shad -256 (K)
// Construct 4 gomb leányvállalatok:
// 1. Encryption A-ból B
key_send_enc = shad -256 (K || «Enc-tól B»)
// 2. titkosítása a B-A
key_recv_enc = shad -256 (K || «Enc B-től A»)
// 3. Azonosítás A-ból B
key_send_auth = shad -256 (K || «Auth-tól B»)
// 4. Hitelesítés a B-A
key_recv_auth = shad -256 (K || «Auth B-től A»)
4. Message Authentication Codes
Minden üzenetet kell kísérnie üzenethitelesítő kód (MAC). Függvényében MAC Schneier és Ferguson használatát javasoljuk HMAC-SHA-256:
Itt ai - a hitelesítési kódot az i-edik km üzenetét. HMACK (m) jelentése hash függvény, amelynek értéke nem csak attól függ az üzenet m, hanem a K kulcs Mivel abban az esetben, titkosítás, két független MAC kulcsot kell használni az A és B Mint már említettük, ⊕ - ez a bitenkénti kizáró VAGY (aka XOR).
A „Gyakorlati rejtjelezés” különös hangsúlyt fektet, mennyire fontos, hogy hitelesítse nemcsak km üzenetét. Ez általában egy byte sorozatot, hanem annak értelmét. Hagyja, mi = a || b || c, akkor épül fel több mező egy bizonyos hosszúságú. Képzeljük el, hogy miután a következő frissítés a protokoll mező mérete megváltozott. Ezután, ha a támadó nem helyettesítheti az E változat a protokoll, az üzenet hibásan értelmezett. Különben is, nem számít, milyen a támadó lesz képes erre - a biztonsági egyik a rendszer nem függ a biztonsági többit.
Ezért több információra van szükségünk xi. beleértve a protokoll azonosítója (aláírás, IP: port a címzett és a feladó), a protokoll verzió, üzenet azonosítója, mérete és nevét üzenet mezőket. Míg információ xi kell kódolni, oly módon, hogy egyedülálló módon dekódolható. L (xi) a mi általános képletű - ez nyilvánvalóan, xi hossza. Szerencsére az összes ezt a szart el lehet kerülni egyszerűen csak be kell üzenetek XML-szerű adatformátum, ami azt jelenti, hogy ha további információt értelmében az üzenet tartalmazza az üzenet is. Fontos, hogy ne felejtsük el, hogy szerepeljenek az egyes üzenetek a további információkat a fent felsorolt.
Mit kell még tudni a MAC?
- Levághatja értékét HMAC-SHA-256 maximum 16 bájt. Ezzel nem kívánatos, de ez a megoldás jobb, mint a használata HMAC-MD5 csökkentése érdekében a továbbított adatmennyiség.
- Javasoljuk, hogy először kiszámítja a MAC, majd titkosítja az üzenetet a MAC. és nem fordítva.
5. üzenetküldés Leírás
Feltételezzük, hogy a felhasználók az A és B már megtette összehangolását session kulcsot és a számított gyermek gombok, amint azt a 3. bekezdés.
Fontos! Minden egyes új munkamenet szükséges új titkosítási kulcsokat és a hitelesítést.
Kulcsegyeztetési érdemel külön bejegyzést írni, ha nem kettő, mert most nem látunk.
Most az A és B üzeneteket váltanak hasonló formátumban XML (vagy kövesse az utasításokat, hogy a biztosított az adott helyzet, lásd 4. bekezdés). Minden üzenet egy egyedi 32 bites szám. Üzenet számozás kezdődik az egység - a könnyebb nyomon követni az idő, amikor a számok elfogynak. Amikor ez megtörténik, akkor újra kell tárgyalások kulcsfontosságú. Ön is használja a 64 bites üzenet számok, de akkor minden üzenet 4 byte hosszú. Emellett időről időre meg kell, hogy frissítse a kulcsokat, hogy a 32 bites - csak jobb.
Ha az adatok UDP protokollt kell újra egy üzenetet küld egy bizonyos idő, ha a másik fél nem reagál rá. Amikor a TCP nem kell - a szállítási réteg vigyázni garantált csomag szállítás. E támadó megzavarhatja a munkamenet A és B között, károsítja az egyik üzenet, vagy átrendezése egy pár üzenetek felcserélhető. De ha van egy „man in the middle”, hogy minden esetben tudja törni a kapcsolatot A és B között a következőket:
Ne pazarolja az idejét írás „TCP» másikkal protokoll - csak a TCP protokollt használják. Természetesen, ha az alkalmazás is lehetséges.
Amikor a felhasználó akar küldeni egy üzenetet, hogy mi. kiszámítja az MAC ezt ai álláshely 4. bekezdés szerint Aztán kódolja az üzenetet km || ai. bekezdésben leírtak szerint 2 a felhasználó B és elküldi a következő: i || m'i || a'i. Ezt követően, az értéke A növeli az elküldött üzeneteket számláló i egy.
Amikor a felhasználó B megkapja i || m'i || a'i. Dekódolja mi és ai. ellenőrzi a hitelesítési kódot. Üzenetek érvénytelen MAC figyelmen kívül hagyja (tudták küldeni a támadó E). Ezután ellenőrzi az értékek i - Ha kevesebb, mint a várt üzenet számát, hogy az a felhívás, hogy j, az üzenet elvész. Ellenkező esetben (i> = j) értékét hozzárendeljük i + j 1 MI, és az üzenet feldolgozására.
Több pontot, amelyen van fókuszban. Először is, mint a 2. bekezdésben említett, az üzenet számát kell továbbítani a byte sorrendben idősebb, fiatalabb. Másodszor, az üzenet számát ellenőrzéseket is lehetne végezni, és dekódolni. De ebben az esetben, ha egy üzenet érvénytelen számú támadó küld E talált (majd jegyezni a napló), a hiba „rossz üzenet szám”, holott nem volt hiba „helytelen Message Authentication Code”. Cryptographers elsősorban aggódik a biztonság és a helyes működését az alkalmazás, hanem a teljesítmény. Néhány programozók sokat tanulhatunk tőlük.
Sajnos, abban az esetben az aktív beavatkozás, hogy a támadó E adatokat, a felhasználó B kaphat csak egy részhalmaza küldött üzenetek A. Ha talált hiányzó üzeneteit, a felhasználók viselkedését kell típusától függ a kicserélt információk. Egyes esetekben az eltűnése az üzeneteket nem lehet kritikus a másik -, hogy a kereslet megszüntetése a kommunikációs esemény.
6. Következtetés
Túl sok pont nem borította ezt a bejegyzést. Mivel az A és B egyetért a munkamenet-kommunikáció kulcsa? Amennyiben alatt kulcsegyeztetési A felhasználó tudja, hogy ő kommunikál B, ha a feltétel az E feladat megszemélyesítheti valaki?
Nem kevésbé érdekes kérdés - hogyan kell létrehozni ál-véletlen számokat? Hogyan kell kezelni az időzítés támadás? Mi a teendő, ha az operációs rendszer fog egy futó alkalmazás összes kulcsot a lapozófájl? Hogyan lehet teljesen eltávolítani a fájlt egy elavult pár RSA-kulcsok? E támadó, bár nem tudom, az üzenet tartalmát, de tudja, méretük és az elküldés időpontjában - függetlenül attól, hogy veszélyes és hogyan ellenállni?