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

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



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

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 34

        0
        Спасибо, отличные статьи, видимо надо лучше осваивать поиск.

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

          0
          Сумбурно как-то, и поверхностно, как по мне, мало информации. Лучше бы более подробно расписали как работает kerberos.
          А насчет хранения паролей в открытом виде — никто, кроме администратора сервера при нормальной настройке эти пароли не посмотрит, и с другой стороны, если администратор сервера захочет, он так или иначе сможет эти пароли получить.
            +1
            Да, у вас гораздо подробнее.

            По поводу паролей — если администратор не управляет центром kerberos или pki, то возможностей подсмотреть пароль у него нет.
              +4
              Я попробую дополнить более полной информацией по kerberos в ближайшее время — материалы есть, надо будет переработать немного.
              +3
              Мне, человеку далёкому от криптографии, понравился топик.
            +3
            Некоторый оффтоп не ради рекламы, а во имя просвещения всех заинтересовавшихся: есть замечательная книжка «Практическая криптография», написанная Нильсом Фергюсоном и Брюсом Шнайером, людьми более чем компетентными в вопросах безопасности информации. Книжка не самая простая для понимания, но очень интересная. Крайне рекомендую к прочтению, ибо даже в самых толстых статьях всего не рассмотреть.

            Ссылки на магазины давать не буду, те, кто заинтересуется сами легко их нагуглят.
              0
              Не вижу ничего оффтопного — очень любезно с вашей стороны прибавит к ликбезу отсыл к самообразованию, для заинтересовавшихся.
              • UFO just landed and posted this here
                  0
                  Советую ещё книгу того же Брюса Шнайера «Прикладная криптография».
                    0
                    Насколько я помню, книга «Практическая криптография» является дальнейшим развитием «Прикладной криптографии» и включает её основные идеи, нет?
                      0
                      Извините, не читал предложенную вами книгу, поэтому не могу ответить, но обязательно прочитаю её.
                        +1
                        Так и есть, «Практическая криптография» — развитие «Прикладной», в ней больше практики в то время, как в «прикладной» большее внимание уделяется теории.
                    0
                    Немного комментариев.

                    «Подобрать входные данные, которые дадут такой же результат… абсолютно не соответствует CRC.»
                    Разве CRC когда-нибудь использовался в криптографии? По моим сведениям — только для проверки целостности данных.

                    «Это лучше чем даже хеш — пароль по сети не бегает вообще, сервер так же не получает ваш секрет — вы проводите с сервером взаимную аутентификацию».
                    Как хеш может быть лучше самого себя? Ведь вы дальше пишете про то, что в Kerberos используется хеширование.
                      0
                      CRC относится к криптографии. Ну как же, если CRC не сходится — это ж сразу возникает мысль «А не изменил кто данные по пути нарошно?»
                        0
                        CRC используется в телекоммуникациях. Но только для того чтобы понять, не был ли поврежден пакет при доставке. Даже если такой пакет подменить, то протоколы высшего уровня (например, SSL, TLS, etc) обязательно это заметят.
                        Поэтому CRC не несет криптографической нагрузки. Насколько меня учили в университете, он даже не является хеш-функцией в привычном понимании.
                          –1
                          Есть такой тип билета в Kerberos des-cbc-crc. Как видим используется, печально только, что в некоторых местах другого типа и нет. К примеру реализация nfsv4 в Linux — не знаю как сейчас, а год назад никаких других типов билетов использовать было нельзя.
                          www.freesoft.org/CIE/RFC/1510/74.htm
                            +2
                            По вашей же ссылке явно написано, для чего там используется CRC, а что отвечает за криптографическую нагрузку (а именно, DES в режисе CBC).
                              0
                              Да, вы правы. CRC явно был помянут не к месту.
                            0
                            CRC использует PGP, когда надо передать информацию в ASCII. Но это я из памяти беру, может ошибаюсь. Но вообще странно как то спорить к чему относится алгоритм — он есть и использоваться может везде где пригодится.
                              0
                              Отчасти корректное утверждение. PGP использует 24-битный CRC код, преобразованный в radix-64 кодировку, для, так называемой, Armor Checksum, сегмента, который помещается перед закрыващим «тегом» зашифрованного сегмента при передаче в ASCII формате.
                              Все это делается исключительно для защиты от ошибок передачи, никакого отношения к криптографии и PGP в данном случае CRC не имеет.
                            +1
                            CRC относится к кодированию информации, к кодам с возможностью обнаружения (но не исправления ни в коей мере) ошибок.
                            И ноги его растут в телекоммуникациях, как верно было замеченно чуть выше. К криптографии он не имеет никакого отношения.

                            У связистов, например, когда CRC не сходится, возникает мысль, что в канале возникли ошибки передачи :)
                            0
                            Согласен, написано немного некорректно, переправлю — лучше метода проверки хеша, имелось ввиду.
                            0
                            « выделен отдельный сервер — Key Distribution Server », а почему тогда дальше по тексту «KDC»? я пропустил где-то что-то?
                              0
                              Key Distribution Center
                                0
                                Спасибо, исправил.
                              +1
                              Для тех, кто хочет криптографию потрогать руками, могу посоветовать jcryptool.sourceforge.net/
                              С помощью этой замечательной программки можно понять, как все это работает.
                              Требует Java, работает на Windows, Mac, Linux.
                              0
                              Все таки процесс установления личности — это _идентификация_. Аутентификация — процесс проверки подлинности представленных идентификацонных данных. Но, возможно, Вы правильно выбросили идентиикацию, чтобы не загромождать текст «идентификацией и аутентификацией».
                                0
                                А что, мд5 уже стал обратим?
                                  +1
                                  Там не говорилось об обратимости, но все таки убрал про MD5 и CRC. — действительно неверная информация, спасибо habrahabr.ru/blogs/infosecurity/50434/
                                  0
                                  спасибо, вспомнил свои пары по защите информации

                                    +2
                                    сколько можно учебник переписывать сюда?

                                    Only users with full accounts can post comments. Log in, please.