Сделал над собой волевое усилие и продолжил писать цикл заметок об использовании криптографии в IT. Это третья часть, по задумке всего их должно быть пять. Первая часть про шифры здесь, вторая часть про доверие здесь. Третья часть — про верификацию отправителя, а также проверку подлинности и целостности полученных данных.
Во второй части я обозначил четыре основных задачи, которые возникают при передачи данных по открытому каналу связи. Напомню их.
- Проверить подлинность открытого ключа (подробный разбор в предыдущей заметке).
- Проверить подлинность и целостность открытого ключа.
- Аутентификация отправителя данных. То есть убедиться в том, что данные пришли действительно от того, о ком мы думаем.
- Проверка целостности данных. То есть удостовериться что их не подменили по дороге.
Несмотря на кажущееся разнообразие, три последних проблемы решаются одними и теми же методами. Поэтому их можно "свалить в одну кучу". Действительно, все они сводятся ровно к следующему.
Вася нам что-то прислал. Неважно что. Письмо, открытку, бандероль, привет. Мы должны понять, что это был действительно Вася и что оно дошло именно в том виде, в каком он нам это "что-то" послал. Как мы можем это сделать в реальной жизни? Очень просто. Пусть Вася упакует свое послание, скажем, в бумажный конверт таким образом, чтобы этот конверт нельзя было бы вскрыть, не причинив последнему необратимых повреждений. После того, как Вася заклеит конверт, он собственноручно распишется на нём. Мы получим конверт, осмотрим его на предмет отсутствия повреждений, надрывов, после чего сверим Васину подпись с ксерокопией странички его паспорта. Нечто подобное практикуется и в IT.
Отправитель (Вася) берет набор данных, который хочет передать, добавляет к ним текущую дату/время, немного какого-нибудь случайного шума и вычисляет от всего этого безобразия хеш. То есть, грубо говоря, применяет к тексту послания необратимое шифрование с потерями (см. часть 1). Затем этот самый хеш он шифрует своим закрытым ключом, то есть тем, который известен ему и только ему. То что получилось в итоге он присоединяет к исходному сообщению и всё вместе отправляет получателю, то есть нам.
Что делаем мы? У нас есть сам текст сообщения и есть к нему "довесок" в виде асимметрично зашифрованного хеша. И у нас есть Васин открытый ключ, причем мы знаем что он точно Васин, поскольку задача №1 уже решена. Несимметричные же алгоритмы устроены таким образом, что используемые в них ключи равноправны. Зашифровали открытым — расшифровали закрытым. И наоборот: зашифровали закрытым — расшифровали открытым. Поэтому обладая открытым Васиным ключом мы можем расшифровать тот самый "довесок" и получить из него хеш сообщения.
А дальше совсем просто. Берем текст "без довеска" и сами вычисляем его хеш. Если он совпал с расшифрованным на предыдущем шаге, то всё хорошо. Сообщение действительно от Васи и его никто не подменил. Если не совпал — отбрасываем его как неблагонадёжное.
Действительно, ведь только Вася обладает Васиным закрытым ключом, по определению. Значит никто кроме него не может зашифровать "довесок" точно так же, как он сам. А если сообщение по дороге подменят или исказят, то его хеш не сойдется с тем, что прикрепит к письму Вася в шифрованном виде.
Такая технология называется "электронная цифровая подпись" (сокращённо "ЭЦП"). Или просто "цифровая подпись". Наиболее распространёнными на сегодняшний день алгоритмами реализации данной технологии являются ElGamal (в основном используется в программном продукте PGP / GnuPG), DSA (используется в X509) и RSA. Разумеется, никто не может запретить применять ЭЦП в связке с "обычными" шифрами. В таком случае передаваемое сообщение будет и зашифровано, и "подписано". Первое не позволит постороннему ознакомиться с его содержимым, второе даёт возможность адресату удостовериться в подлинности полученного, то есть аутентифицировать отправителя.
Ну а когда передаются большие объемы данных (например, организован поток от веб-сервера к веб-клиенту), то для каждого передаваемого в пределах одного и того же сеанса связи пакета не имеет смысла каждый раз заново генерировать и пересылать ЭЦП. Это слишком расточительно как по задействуемым вычислительным ресурсам, так и по количеству паразитного трафика. Поэтому в таких случаях поступают несколько по-другому.
Как только стороны удостоверились в подлинности контрагента, то есть аутентифицировали друг друга (например, посредством всё той же ЭЦП), они случайным образом генерируют комплект сеансовых ключей. В него входят ключи для симметричного шифрования и расшифровки данных в пределах данного сеанса, а также некий секретный параметр для вычисления хешей по особому заранее выбранному алгоритму. Теперь отправителю достаточно всего-навсего сперва посчитать так называемый HMAC (Hash-Based Message Authentication Code: код аутентификации на основе хеша), прикрепить его к исходному сообщению, а потом зашифровать всё вместе симметричным алгоритмом при помощи выбранного временного сеансового ключа. Так получается, что и овцы целы, и волки сыты и данные надёжно передали, и скорость не сильно пострадала.