1. Отчет за проблема

Има потребители А и В, които обменят съобщения. Те могат да използват TCP, UDP, електронна поща или чат - сега това няма значение. Има E нападател, който може да се намеси, сменете и реорганизиране на тези съобщения, за да ги изчезват без следа, и изпращане на съобщения от името на А и Б. Задачата - да се помогне на А и обмен B съобщения по начин, който Е не може да намери тяхното съдържание. Отърви се от Е не може да бъде.

Encryption 2. Данни

Като алгоритъм за криптиране Шнайдер и Фъргюсън препоръчваме използването на AES (Rijndael с 128-битов блок) от дължината на ключа 256 бита в режим CTR. В този режим, максималният размер на съобщение е 16 · 2 32 байта. Малко вероятно е, че някой дистрес това ограничение. В краен случай, можете да разделяте съобщение на части.

Криптиране на съобщение с номера и с размери L бита, L малко е необходимо, за да се изчисли по следния начин:

където EK функция (128-битов изход) - криптиращия алгоритъм К (256 бита) - ключ за шифриране аргумент на функция (128-битов) - криптира данни и || Това означава, че данните конкатенация. След изчисляване на бита b1 ... бл ги добавите в Zhegalkin (ексклузивно, операция XOR, ⊕) с бита на съобщението, резултатът е ciphertext. За да декодирате трябва да направите точно същата последователност от действия над ciphertext.

Важно е да се обърне внимание на две точки. На първо място, криптиране ключовете при изпращане на данни от А до точка Б и от Б до А трябва да е по-различно. На второ място, е необходимо да се споразумеят за последователност от байтове в функцията аргумент EK. Заповедта байт на 32-битови числа може да варира в зависимост от архитектурата на процесора. Традиционно, мрежови протоколи и файлови формати, използвани по реда байт от най-старите до най-малката.

3. хеш функция

Да кажем, че ние успешно създаден ключ за достъп с използване на алгоритъма Diffie-Hellman. в резултат на А и Б получава общ ключ К. След това следващата последователност от събития:

// Отърви се от ключово алгебрични структура
К = Шед -256 (К)
// Construct 4 основни дъщерни дружества:
// 1. криптиране от А до В
key_send_enc = карагьоз -256 (K || «Enc от А до Б»)
// 2. Encrypt от В до А
key_recv_enc = карагьоз -256 (K || «Enc от Б до А»)
// 3. удостоверяване от А до В
key_send_auth = карагьоз -256 (K || «упълномощаване от А до Б»)
// 4. удостоверяване от В до А
key_recv_auth = карагьоз -256 (K || «упълномощаване от Б до А»)

4. Съобщението за удостоверяване кодове

Всяко съобщение трябва да бъде придружен от код за удостоверяване за съобщения (MAC). Като функция на MAC Шнайдер и Фъргюсън препоръчваме използването на HMAC-SHA-256:

Тук AI - за удостоверяване кода на I-та миля постове. HMACK (т) представлява разбъркваща функция, чиято стойност зависи не само от М съобщение, но също така и от ключ К. Както в случая на криптиране, в два независими ключ MAC трябва да се използва за А и В. Както вече бе отбелязано, ⊕ - е побитов изключителен-OR (известен още като XOR).

В "Практически Криптографията" отдава голямо значение на колко важно е за удостоверяване не само мили постове. Обикновено е един байт последователност, но и неговото значение. Нека ми = а || б || С, след това там е съставена от няколко полета с определена дължина. Представете си, че след следващата актуализация на размерите на полеви протокол са се променили. След това, ако един хакер може да замести E версия на протокола, съобщението ще се тълкува неправилно. Освен това, без значение колко нападателя ще бъде в състояние да направи това - сигурността на една от системата трябва да не зависи от останалата част на безопасността.

Ето защо имаме нужда от повече информация XI. включително идентификатор протокол (подпис, IP: порт на получателя и подателя), протокол версия, ID съобщение, размера и имената на полета съобщения. Докато информация XI трябва да бъдат кодирани по такъв начин, че да може да бъде еднозначно декодира. L (XI) в нашата формула - това е очевидно, дължина XI. За щастие, всички тези глупости може да се избегне само чрез преминаване на съобщения във формат XML с подобни данни, което означава, че когато допълнителна информация за смисъла на посланието е включена в самото съобщение. Важно е да не се забравя да се включат във всеки съобщение цялата допълнителна информация, изброени по-горе.

Какво друго трябва да знам за MAC?

• Можете да отрежете стойността на HMAC-SHA-256 до 16 байта. По този начин не е желателно, но това решение е по-добре, отколкото използването на HMAC-MD5, за да се намали обема на предаваните данни.
• Препоръчително е първо да се изчисли на МАС, след което криптира съобщението с MAC. а не обратното.

5. съобщения Описание

Предполагаме, че потребителите А и Б вече са направили координация на ключа за достъп и изчислените ключовете на детето, както е описано в параграф 3.

Важно! За всяка нова сесия е необходимо да се генерират нови ключове за криптиране и автентификация.

Ключови съгласие заслужава отделен пост да пиша, ако не и две, защото в момента ние не виждаме.

Сега и обмен B съобщения във формат, подобен на XML (или следвайте инструкциите, които са предвидени за тази ситуация, виж точка 4). Всяко съобщение се получава уникален номер 32-битова. номерация Съобщението започва с единица - това е по-лесно да следите на времето, когато цифрите се изчерпят. Когато това се случи, трябва да предоговаряне е от ключово значение. Можете също така да се използва 64-битови числа на съобщенията, но след всяко съобщение ще е с дължина 4 байта. В допълнение, от време на време трябва да бъде да се актуализира ключовете, така че 32-битова - точно.

Ако данните използва UDP протокол следва да бъде повторно изпращане на съобщение през определен интервал от време, от друга страна, не реагира на него. При използване на TCP не е нужно да - транспортния слой, за да се грижи за гарантирана доставка пакет. E хакер може да наруши функционирането на сесията между А и Б, повреждане едно от посланията, или пренареждане на няколко съобщения разменят. Но след като имаме "човек по средата", че във всеки случай той може да се прекъсне връзката между А и Б. В заключение:

Не губете време в писане "му TCP» над друг протокол - просто използвайте протокола TCP. Разбира се, ако приложението ви е възможно.

Когато потребител А иска да изпрати съобщение до миля. то изчислява МАС този ай мнения в съответствие с параграф 4. След това той криптира съобщение МВР || ай. както е описано в параграф 2 от потребител B и изпраща следното: || m'i || a'i. След това, стойността на А увеличава изпратените съобщения се противопоставят и по един.

Когато потребител Б получава аз || m'i || a'i. го разшифрова ми и AI. проверява кода за удостоверяване. Съобщения с невалиден MAC игнорирани (те биха могли да изпрати нападателя E). След това проверява стойностите на I - Ако има по-малко от очаквания брой на съобщението, че са специфични това обаждане й, съобщението се изхвърли. В противен случай (I> = й) определяне на стойността на I + J 1 мл и обработва съобщението.

Има няколко точки, по които има фокус. На първо място, както е посочено в параграф 2, броят на съобщението трябва да бъде предадено в реда байт от години, за да по-млади. На второ място, проверките за брой съобщения могат да се извършват и да декодира. Но в този случай, ако се установи, съобщение с невалиден номер атакуващият изпраща E (и след това записва в дневника), грешката "грешен номер на съобщение", когато в действителност е имало грешка "неправилна Message Authentication Code". Криптографите основно загрижени за безопасността и правилното функциониране на заявлението, а не на изпълнението. Някои програмисти имат много да се учим от тях.

За съжаление, в случай на активна намеса на данни с хакер Е, потребителското Б може да получи само част от съобщенията, изпратени до А. Ако открити липсващи съобщения, поведението на потребителите трябва да зависят от вида на информацията, която се обменя. В някои случаи, изчезването на съобщенията може да не е от решаващо значение при друга - да поиска прекратяване на комуникационната сесия.

6. Заключение

Твърде много въпроси, които не са били покрити в тази публикация. Както А и Б се споразумеят за сесия комуникация ключ? Когато по време на ключова съгласие на потребителя на знае, че той комуникира с Б, ако условието на задачата за E може да се представяте за някого?

Не по-малко интересни въпроси - как да генерират псевдо-случайни числа? Как да се справим с времето атаки? Какво трябва да направя, ако операционната система ще постави работеща програма с всички ключове в файла за виртуална памет? Как да премахнете напълно на файл от една остаряла двойка RSA ключове? E нападателя, въпреки че не знаят съдържанието на съобщенията, но знае, техния размер и по време на изпращане - независимо дали това е опасно и как да му се противопоставят?

Подобно на този пост? Споделете с другите: