Pull to refresh

Ликбез по основам безопасности и криптографии

Reading time 6 min
Views 11K

Криптография



Три кита криптографии — хеш, шифрование симметричное, шифрование асимметричное (с открытым ключом). Основываются криптографические алгоритмы на сложности вычисления больших чисел, но подробнее об этом, если вас конкретно интересует «начинка», стоит читать не в общих обзорах, именуемых ликбезом. Здесь же содержится простое изложение, без лишних заморочек, то есть поверхностное.

Хеш — функция, функция «в одну сторону», так как восстановить данные, из которых путем хеширования получен хеш (результат хеш-функции), невозможно. На вход подается информация, на выходе имеем её отпечаток, строку фиксированной длины. Подобрать входные данные, которые дадут такой же результат должно быть сложной задачей. Отсюда следствие — если у вас есть проверенный хеш образа диска, документа и т.п., то вы можете вычислить хеш полученного файла и сравнить — если совпадут, значит это то самое. Подобным же образом обходятся зачастую с паролями — если хеш полученного пароля совпадет с имеющимся (в /etc/shadow к примеру), то проверка пройдена успешно.

Шифрование симметричное — шифрование в котором используется, соответственно, симметричный ключ. Это говорит о том, что если вы что то архиважное зашифровали один ключом, то обратную операцию надо проделать им же. Также может использоваться при проверке знания секрета — шифруем некую информацию этим самым секретом, или его хешем, передаем результат второй стороне. Вторая сторона, которая как предполагается знает секрет, расшифровывает данные, их дополняет, шифрует, пересылает обратно. Первая сторона, получив ответ опять же его расшифровывает и смотрит правильно ли вторая сторона изменила данные. Понятно, что если вторая или первая сторона подсовывает неверный секрет, процесс сорвется. Это было весьма общее описание процессов происходящих в протоколе Kerberos.

Шифрование асимметричное — шифрование в котором используются, два ключа, которые обычно называют приватный (секретный) и публичный (известен всем). Зашифровав что либо одним из пары ключей, обратно расшифровать можно только вторым. Таким образом проверить ваше знания приватного ключа достаточно просто — шифруем некую информацию вашим публичным ключом и, если вы знаете приватный, вы легко её прочитаете. На шифровании с асимметричными ключами построено много систем, к примеру это PGP и PKI. Также каждый из вас пользовался этим видом криптографии когда обращался на адреса вида https: //.

Аутентификация и авторизация



Аутентификация это процесс установления личности. Когда вы вводите пароль на Хабр, вы аутентифицируетесь. Никаких прав вы при этом не получаете.

Авторизация это процесс, в котором проверяются права пользователя на выполнение каких либо действий в системе. Например по умолчанию вы имеете право писать в личный блог, но система не даст вам опубликовать хабратопик в коллективный блог, если у вас будет мало кармы. Здесь авторизация на совершение какого либо действия производится по количеству кармы, в файловых системах вам выдают право на совершение действий через ACL, членство в группе и так далее.

Еще раз — через процесс аутентификации получить право на выполнение чего либо нельзя, этим занимается процесс авторизации, а аутентификация только устанавливает личность.

Аутентификация, немного о криптографической стороне дела



Зачастую аутентификация основывается на проверке знания секрета. Самый простой способ это получить от вас пароль в чистом виде (!) и сравнить с хранящимся в базе. Тут есть вариант — проверять хеш пароля, что позволит не знать пароль серверу, а хранить его хеш. Но заметьте — пароль проходит в открытом виде по сети! Второе — вы не знаете кому отправили свой пароль, сервер может быть подставным. Обходной маневр — использовать только в связке с SSL/TLS, но в таком случае у сервера должен быть корректный, не просроченный сертификат, выданный доверенным центром, а не как обычно.

Второй вариант — сервер знает секрет, вы его знаете — используется метод, описанный в абзаце по симметричному шифрованию. Это лучше чем сравнение с запомненным хешем — пароль по сети не бегает вообще, сервер так же не получает ваш секрет — вы проводите с сервером взаимную аутентификацию. На этом методе вырос весьма серьезный протокол — Kerberos, с одним нюансом — пароли знают только выделенные сервера в сети. Kerberos используется в Microsoft Active Directory, в качестве примера привожу как самый известный продукт — все таки у нас ликбез.

Третий вариант, сложный, PKI. За рамки ликбеза его описание выходит, интересно — почитайте сами. По сути схож с Kerberos — есть центр, но основан на асимметричном шифровании.

Kerberos



Алгоритм описан с некоторыми отступлениями, для улучшения восприятия. Если вам потребуется точное описание работы, не для общего сведения, советую почитать более серьезную литературу

Каждый день, работники корпоративного сектора активнейшим образом используют квинтэссенцию криптографической мысли — протокол Kerberos, бороздя просторы корпоративной же сети построенной на базе решений от Microsoft, ведь все процессы идентификации пользователей и компьютеров сервисами (IMAP,SMTP, доступ к файлам) он берет на свои плечи.

Протокол Kerberos это протокол аутентификации использующий хеш-функции и симметричные шифры. Как ни удивительно, но Kerberos это не очередное порождения Microsoft в стремлении «чтобы свое, и чтобы ни с чем не совместимо, и чтобы они нам душу отдали за спецификации», создан протокол в стенах массачусетского технологического института — MIT, где активно используется все эти годы в кампусной сети ВУЗа.

Перечитайте описание симметричных шифров, в конце там есть пример. Так вот в чем недостаток решения, предложенного в том абзаце? А получается, что пароли надо размещать на каждом сервере сети, да еще каждой службе надо будет иметь к ним доступ, к незашифрованым паролям, да еще на каждый сервер эти пароли надо внести. Выглядит это несколько дыряво.

В протоколе Kerberos для хранения паролей выделен отдельный сервер — Key Distribution Center (сервер распределения ключей), ключи есть у каждого участника процесса — и у пользователей и у сервисов. Ключ получается из пароля путем хеширования, так как пользователь не сможет запомнить требуемое для алгоритма шифрования количество символов. Хеширование возвращает всегда строку фиксированной длины, что как раз подходит для алгоритмов шифрования с симметричным ключом.

Когда пользователю надо получить доступ к HTTP серверу (портал там лежит корпоративный, к примеру), он обращается к KDC (ну понятно, что обращается библиотека) с просьбой предоставить ключ для доступа к HTTP серверу. У KDC есть ключи пользователя и сервера

KDC генерирует случайный, симметричный ключ и делает достаточно сложную конструкцию, называемую билетом, которую лучше посмотреть на картинке:



Итак, имеем матрешку, но разбирается она достаточно просто. Пользователь, получив ответ, расшифровывает его свои ключом, получает сгенерированный ключ и шифрованный ключом сервера пакет. Так вот этот пакет пользователь отсылает уже HTTP серверу, который расшифровывает его и тоже получает тот же самый сгенерированный ключ.

Теперь у обоих есть общий ключ. И вот теперь можно аутентифицировать друг друга, способ уже описан — шифруем полученным от KDC, сгенерированным ключом имя пользователя, IP адрес, время и отсылаем серверу. Сервер расшифровывает, и получив ожидаемое имя пользователя признает в нем Пупкина. Теперь очередь сервера представиться — он прибавляет к полученному времени 1 (единицу) и, зашифровав все обратно, отсылает пакет пользователю. Ясно, что если в полученном пакете, после дешифрации будет обнаружена та же временная метка, которую пользователь отсылал, но увеличенная на единицу, то сервер признается подлинным.

А вот про время я упомянул не зря. Доступ выдается на определенное время (часто на 10 часов), время проставляется в билете, и по истечении срока действия билет считается просроченным — сервер больше такой билет не примет, что впрочем не смертельно — получите новый. Гораздо печальнее будет, если время на вашем ПК разойдется более чем на 5 минут с KDC — войти в систему не сможете, так как протокол Kerberos требует от участников процесса синхронного времени — чтобы билеты истекали на всех машинах сети одновременно, и не было возможности использовать просроченный билет для доступа куда либо.

Итак, билет действует 10 часов, не требуя больше ввода пароля, для обращения к серверу. Но ведь так утомительно вводить пароль на каждый сервер в сети, тем более, что вы могли заметить — никто так не делает, после одного ввода пароля при логине в Windows вы больше не вводите пароли на доступ к расшареным сетевым папкам. А все от того, что получать билеты ведь тоже можно по билету! Подобная конструкция называется TGT — билет для получения билетов. Тут все так же как и было показано, получаем билет на доступ к сетевой службе, выдающей билеты (TGS — Ticket-Granting Service), которая признает Пупкина Пупкиным. А раз Пупкин это Пупкин, то можно ему выдавать билеты на Пупкина для доступа к различным серверам сети.

Таким образом, в течении действия TGT вы можете получать билеты на доступ к сетевым службам без повторного ввода пароля. Удобно работает, правда?

Заметьте, что Kerberos выдает билеты на доступ к любой службе сети, есть ли у вас право ей пользоваться или нет, протоколу аутентификации безразлично — его дело удостоверить вашу личность, а правами занимаются совсем другие механизмы.

P.S. В остальных ОС Kerberos также работает. Windows в качестве примера выступает из-за большей распространенности, и, как следствие, большей наглядности в повседневной жизни.

P.P.S. В комментариях есть ссылки на более подробное изложение некоторых аспектов, если интересно узнать больше и подробнее — читайте.
Tags:
Hubs:
+52
Comments 34
Comments Comments 34

Articles