Добавлен: 29.10.2018
Просмотров: 48140
Скачиваний: 190
9.5. Основы криптографии
691
D и E должны быть коммутативными функциями. К счастью, у алгоритма RSA такое
свойство есть.
Чтобы воспользоваться этой схемой электронной подписи, получатель должен знать
открытый ключ отправителя. Некоторые пользователи выкладывают применяемые
ими открытые ключи на своей веб-странице. Другие этого не делают, опасаясь, что
злоумышленники взломают веб-страницу и незаметно изменят их ключ. Им для
распространения открытых ключей нужен какой-нибудь другой механизм. Одним
из распространенных методов для отправителей сообщений является прикрепление
к сообщению сертификата (certificate), в котором содержатся имя пользователя
и открытый ключ и который имеет цифровую подпись вызывающей доверие третьей
стороны. Как только пользователь получает открытый ключ этой третьей стороны, он
может принимать сертификаты от всех отправителей, пользующихся услугами этой
третьей доверенной стороны, чтобы генерировать их сертификаты.
Доверенная третья сторона, подписывающая сертификаты, называется центром
сертификации
(Certification Authority (CA)). Однако для того чтобы пользователь
проверил сертификат, подписанный CA, ему нужен открытый ключ этого центра. От-
куда он должен прийти и как пользователь может убедиться в его подлинности? Для
того чтобы это сделать в общепринятом порядке, нужна полная схема управления от-
крытыми ключами, которая называется инфраструктурой открытых ключей (Public
Key Infrastructure (PKI)). Для веб-браузеров эта проблема решается особым образом:
все браузеры поставляются с предустановленными открытыми ключами от примерно
40 центров сертификации.
Ранее было рассмотрено применение шифрования с открытым ключом для цифровых
подписей, но следует отметить, что существуют также схемы, в которых шифрование
с открытым ключом не применяется.
9.5.5. Криптографические процессоры
Для всех систем шифрования необходимы ключи. Если ключи скомпрометированы,
то скомпрометирована и вся основанная на их использовании система безопасности.
Поэтому особую важность приобретает безопасное хранение ключей. Но как же орга-
низовать безопасное хранение ключей на небезопасной системе?
Одним из предложений промышленности стала микросхема под названием модуль
надежной платформы
(Trusted Platform Module (TPM)), представляющая собой
криптографический процессор, имеющий в своем составе энергонезависимую память
для хранения ключей. TPM способен выполнять такие криптографические операции,
как шифрование блоков открытого текста или дешифрование блоков зашифрованного
текста в оперативной памяти. Также он может проверять цифровые подписи. За счет
выполнения всех этих операций специализированной аппаратурой существенно по-
вышаются скорость работы и вероятность их более широкого применения. Многие
компьютеры уже оборудованы криптопроцессорами TPM, и, скорее всего, в будущем
количество таких компьютеров значительно возрастет.
TPM — весьма спорное устройство, поскольку у разных сторон есть различные идеи
о том, кто будет управлять TPM и что и от кого оно будет защищать. Большим привер-
женцем этой концепции является корпорация Microsoft, которая разработала целую се-
рию технологий ее использования, включая Palladium, NGSCB и BitLocker. По мнению
специалистов этой корпорации, операционная система управляет криптопроцессором
692
Глава 9. Безопасность
и использует его, к примеру, для шифрования содержимого жесткого диска. Но ей
также хочется использовать его с целью предотвращения запуска запрещенного про-
граммного обеспечения. Запрещенное программное обеспечение может быть пиратской
(то есть нелегально скопированной) программой или программой, которую не раз-
решает запускать операционная система. Если TPM привлекается к процессу запуска
системы, он может запускать только операционную систему, подписанную секретным
ключом, который производитель поместил внутри TPM. Воспользоваться им могут
только избранные поставщики операционной системы (например, Microsoft). Таким
образом, TPM мог бы использоваться для того, чтобы ограничить пользовательский
выбор программного обеспечения тем, которое одобрено производителем компьютера.
Музыкальная и киноиндустрия также сильно стремятся к применению криптопро-
цессоров TPM, поскольку они могут быть использованы для пресечения пиратства по
отношению к распространяемой ими продукции. Они могут также предоставить новые
бизнес-модели, например прокат песен или фильмов на определенный период времени
за счет отказа в их дешифрации по истечении назначенного срока.
Один из интересных способов применения криптопроцессоров TPM известен как
удаленная аттестация
(remote attestation), он позволяет внешней стороне проверять
факт запуска на компьютере с TPM должного программного обеспечения, исключая
что-либо, чему нельзя доверять. Идея заключается в том, что подтверждающая сто-
рона использует TPM для создания критериев приемлемости, состоящих из хэшей
конфигурации. Представим себе, к примеру, что внешняя сторона не доверяет ничему
на нашей машине, за исключением BIOS. Если бы проверяющая (внешняя) сторона
могла убедиться в том, что у нас запущен надежный загрузчик, а не какой-нибудь под-
дельный программный компонент, это было бы только началом. Если кроме этого мы
могли бы доказать, что у нас этим заслуживающим доверия загрузчиком запущено
приемлемое ядро, было бы еще лучше. А если бы в конечном счете мы могли показать,
что на основе этого ядра у нас запущена правильная версия легального приложения,
проверяющая сторона могла бы быть уверена в нашей надежности.
Для начала давайте посмотрим, что произойдет на нашей машине с момента ее за-
грузки. Когда начнет работать надежная базовая система ввода-вывода — BIOS,
сначала она инициализирует TPM и воспользуется им для создания хэша кода, нахо-
дящегося в памяти после загрузки начального загрузчика. TPM записывает результат
в специальный регистр, известный как регистр конфигурации платформы (Platform
Configuration Register (PCR)). Регистры PCR отличаются тем, что не могут быть
переписаны напрямую, они могут быть только расширены. Чтобы расширить PCR,
криптопроцессор TPM берет хэш сочетания введенного значения и предыдущего зна-
чения с PCR и сохраняет его в PCR. Таким образом, если наш начальный загрузчик
доброкачественный, он получит оценочный критерий (создаст хэш) для загружаемого
ядра и расширит PCR, в котором ранее хранился оценочный критерий для самого
начального загрузчика. Интуитивно мы можем рассматривать получающийся в PCR
криптографический хэш как хэш-цепочку, связывающую ядро с начальным загрузчи-
ком. Теперь уже ядро в свою очередь создает оценочный критерий для приложения,
которым расширяет PCR.
Теперь давайте посмотрим, что произойдет, когда внешняя сторона захочет убедиться
в том, что нами запущен приемлемый (заслуживающий доверия) стек программ, не со-
держащий никакого произвольного постороннего кода. Сначала проверяющая сторона
создает непредсказуемое значение, к примеру, из 160 бит. Это значение, известное как
9.6. Аутентификация
693
случайный код
(nonce), является для этого проверочного запроса просто уникальным
идентификатором. Он служит для предотвращения несанкционированной записи
ответа на удаленный аттестационный запрос, изменения конфигурации подтвержда-
ющей стороны с последующим простым воспроизведением предыдущего ответа на
все следующие аттестационные запросы. Введение в протокол случайного кода делает
подобное воспроизведение невозможным. Когда подтверждающая сторона получает
аттестационный запрос (со случайным кодом), она использует TPM для создания
сигнатуры (с уникальным и неподделываемым ключом) для объединения случайного
кода и значения PCR. Затем эта сигнатура, случайный код, значение PCR и хэши для
начального загрузчика, ядра и приложения отправляются назад. Проверяющая сто-
рона сначала проверяет сигнатуру и случайный код. Затем она ищет три хэша в своей
базе данных надежных начальных загрузчиков, ядер и приложений. Если их там нет,
аттестации не происходит. В противном случае проверяющая сторона заново создает
объединенный хэш всех трех компонентов и сравнивает его со значением PCR, полу-
ченным от подтверждающей стороны. Если значения совпадают, проверяющая сторона
убеждается в том, что подтверждающая сторона начала свою работу именно с этих трех
компонентов. Результат, имеющий подпись, не позволяет взломщику его подделать,
и поскольку нам известно, что надежный начальный загрузчик создал соответствую-
щий оценочный критерий ядра, а ядро в свою очередь создает оценочный критерий для
приложения, то никакая другая кодовая конфигурация не сможет произвести такую
же цепочку хэшей.
TPM находят множество других вариантов применения, рассмотрение которых вы-
ходит за рамки этой книги. Любопытно, что при всех своих возможностях TPM не
может сделать компьютеры лучше защищенными от внешних атак. Его задачи концен-
трируются на использовании криптографии с целью воспрепятствовать каким-либо
действиям пользователя, которые прямо или косвенно не санкционированы тем, кто
управляет TPM.
9.6. Аутентификация
Каждая надежная (secured) компьютерная система должна требовать от всех пользо-
вателей во время входа проходить аутентификацию. Ведь если операционная система
не может быть уверена в том, кем именно является пользователь, она не может знать,
к каким файлам и другим ресурсам он может иметь доступ. Несмотря на то что тема
аутентификации может показаться слишком тривиальной, она намного сложнее, чем
можно было бы ожидать.
Аутентификация пользователя относится к тем вещам, о которых шла речь в главе 1
в разделе «Онтогенез повторяет филогенез». У ранних моделей универсальных машин,
таких как ENIAC, не было операционной системы, не говоря уже о процедуре входа в си-
стему. Более поздние пакетные системы и системы разделения времени уже, как правило,
имели процедуры входа в систему для аутентификации заданий и пользователей.
У первых мини-компьютеров (например, PDP-1 и PDP-8) также не было процедуры
входа в систему, но с распространением операционной системы UNIX на мини-ком-
пьютере PDP-11 такая процедура снова стала востребованной. Первые персональные
компьютеры (например, Apple II и исходная версия IBM PC) не имели процедуры вхо-
да в систему, но она появилась в более сложных операционных системах для персональ-
694
Глава 9. Безопасность
ных компьютеров, например в Linux и Windows 8 (хотя недальновидные пользователи
могут ее отключить). И наконец, многие в наше время входят (опосредованно) в систе-
му удаленных компьютеров с целью использования интернет-банкинга, совершения
электронных покупок, загрузки музыки и осуществления других видов деятельности.
Все эти действия требуют аутентифицированного входа в систему.
Убедившись в важности аутентификации, следует перейти к поиску подходящего спо-
соба ее осуществления. Многие способы аутентификации пользователей при попытке
их входа в систему основываются на трех основных принципах, а именно:
на чем-нибудь, что известно пользователю;
на чем-нибудь, что есть у пользователя;
на чем-нибудь, что он собой представляет.
Иногда два из них нуждаются в дополнительных мерах безопасности. На основе этих
принципов выстраиваются различные схемы аутентификации со своими сложностя-
ми и свойствами безопасности. Все они по очереди будут рассмотрены в следующих
разделах.
Наиболее широкое применение нашла форма аутентификации, требующая от поль-
зователя ввода регистрационного имени и пароля. Парольную защиту проще понять
и реализовать. Наипростейшая реализация заключается в поддержке главного реестра
пар (регистрационное имя, пароль). Введенное регистрационное имя ищется в реестре,
и введенный пароль сравнивается с хранящимся паролем. Если они совпадают, вход
в систему разрешается, если нет, он отклоняется.
Практически всегда вводимый пароль не отображается на экране, чтобы спрятать его
от любопытных глаз, находящихся возле монитора. В системе Windows каждый на-
бранный символ отображается звездочкой. В системе UNIX при вводе пароля вообще
ничего не отображается. Эти две схемы обладают разными свойствами. Схема, исполь-
зуемая в Windows, упрощает забывчивым пользователям отслеживание количества
набранных символов, но она также раскрывает длину пароля для подглядывающих.
С точки зрения безопасности молчание — золото.
Другая область, где оплошности могут серьезно повлиять на уровень безопасности, по-
казана на рис. 9.15. Успешный вход в систему, когда система выводит сообщения в верх-
нем регистре, а пользователь осуществляет ввод в нижнем, показан на рис. 9.15, а. На
рис. 9.15, б показана неудачная попытка взломщика войти в систему А, а на рис. 9.15, в
показана неудачная попытка взломщика войти в систему B.
Рис. 9.15. Вход в систему: а — успешный; б — отказ во входе после ввода имени;
в — отказ во входе после ввода имени и пароля
На рис. 9.15, б система отказывает во входе, как только видит неверное регистраци-
онное имя. Это считается ошибкой, поскольку позволяет взломщику продолжать
подбор регистрационного имени до тех пор, пока не будет найдено подходящее имя.
На рис. 9.15, в у взломщика всегда запрашивают пароль, и его не оповещают о том,
9.6. Аутентификация
695
является ли введенное им регистрационное имя подходящим. Он узнает только о том,
что испробованная им комбинация регистрационного имени и пароля является не-
подходящей.
Кроме процедур входа в систему большинство ноутбуков настроены на то, что им нуж-
ны регистрационное имя и пароль для защиты их содержимого на случай потери или
кражи. Конечно, это лучше, чем ничего, но ненамного. Любой завладевший ноутбуком
может включить питание и тут же войти в программу настройки BIOS, удерживая
клавишу
Del
, или клавишу
F8
, или какую-нибудь другую клавишу, связанную с вы-
зовом настроек BIOS (информация о которой обычно выводится на экран) до запуска
операционной системы. В программе настройки он может изменить последователь-
ность используемых устройств запуска, предписав компьютеру запускаться с флеш-
накопителя USB перед запуском с жесткого диска. Затем нашедший ноутбук вставляет
флеш-накопитель USB, содержащий полноценную операционную систему, и запускает
компьютер с этого накопителя. После запуска операционной системы жесткий диск
может быть смонтирован (в UNIX) или доступен как устройство
D:
(в Windows).
Чтобы предотвратить возникновение подобной ситуации, многие системы BIOS по-
зволяют пользователю защитить паролем программу настройки BIOS, чтобы только
пользователь мог изменить последовательность опроса устройств при загрузке. Если
вы пользуетесь ноутбуком, прервите чтение книги и займитесь установкой пароля на
свой BIOS, а затем вернитесь к чтению.
9.6.1. Слабые пароли
Зачастую взломщики проникают в систему, подключившись к намеченному компьюте-
ру (например, через Интернет) и перебирая множество комбинаций (регистрационное
имя, пароль) до тех пор, пока не найдут одну из действующих комбинаций. Многие
люди в той или иной форме используют в регистрационном имени свое настоящее
имя. Например, для Ellen Ann Smith соответствующими вариантами могут быть ellen,
smith, ellen smith, ellen-smith, ellen.smith, esmith, easmith и eas. Вооружившись одной
из книг вроде «4096 имен для вашего новорожденного» и телефонной книгой, запол-
ненной фамилиями, взломщик запросто может составить компьютеризированный
список потенциальных регистрационных имен для той страны, чью систему он атакует
(ellen_smith в равной степени может сработать в США или Великобритании, но, на-
верное, не в Японии).
Разумеется, разгадки одного только регистрационного имени недостаточно. Нужно
еще отгадать пароль. Трудно ли это сделать? Намного проще, чем вам кажется. Клас-
сический труд по безопасности паролей в системах UNIX был выполнен Моррисом
и Томпсоном (Morris and Thompson, 1979). Они составили список вероятных паролей:
имен и фамилий, названий улиц, названий городов, слов из средних по объему слова-
рей (а также слов в обратном написании), регистрационных номеров и т. д. Затем они
сравнили свой список с системным файлом паролей в поиске совпадений. Более 86 %
всех паролей обнаружились в их списке.
Если кто-то думает, что более высококвалифицированные пользователи подбирают
более удачные пароли, то смею уверить: это не так. Когда в 2012 году в Интернет после
взлома попали 6,4 млн хэшированных паролей LinkedIn, анализ результатов многих
позабавил. Наиболее популярным паролем было слово «password». Вторым по по-
пулярности был пароль «123456» (в десятку наиболее популярных входили «1234»,