ПРОБЛЕМЫ СОЗДАНИЯ ЗАЩИЩЕННЫХ ХРАНИЛИЩ ДАННЫХ В ЕДИНОЙ ИНФОРМАЦИЛННОЙ ОБРАЗОВАТЕЛЬНОЙ СРЕДЕ
И. И. Крисюк, С. А. Минеев
Томский государственный университет
Способ защиты данных, наиболее распространенный в настоящие время, заключатся в создании защищенного интерфейса взаимодействия с хранилищем данных. Его бесспорным достоинством является то, что такая система может быть разделена на два независимых уровня. Нижний уровень отвечает за доступ к данным на физическом носителе, используя все современные алгоритмы индексации и поиска, и не зависит от средств защиты. Второй уровень обеспечивает защищенный доступ к нижнему уровню. Однако этот способ обладает следующим недостатком: если злоумышленник обратится к хранилищу, минуя второй уровень, получив в свое распоряжение, например, жесткий диск, то он получит и полный доступ к данным.
В этой связи систему управления данными будем называть защищенной (кратко: ЗАСУД), если она обладает средствами защиты от несанкционированного доступа как через интерфейс взаимодействия с хранилищем данных, так и непосредственно к информации на физическом носителе.
Один из возможных способов создания ЗАСУД связан с использованием защищенных файловых систем. Данные в таких файловых системах хранятся в зашифрованном виде, причем процесс шифрования происходит прозрачно для приложений, в том числе для системы управления данными. Иначе говоря, снова имеется двухуровневая система, защита данных в которой осуществляется на нижнем уровне, а все функции по управлению и доступу к структурированной информации остаются на верхнем уровне и могут использовать все современные алгоритмы индексации и поиска. Недостатком этого способа является то, что файловая система ничего не знает о структуре данных и вынуждена шифровать/расшифровывать в информацию, включая и служебную информацию (индексы, метаданные и т.д.), время доступа к которой критично с точки зрения эффективности и скорости системы, что резко снижает общую производительность ЗАСУД.
Альтернативный подход к построению ЗАСУД не предполагает разделения защиты и хранения данных по уровням. В этом случае вряд ли можно использовать существующие алгоритмы в области хранения и обработки информации, но зато возможно получить ЗАСУД, которая по эффективности сравнима с не защищенными системами управления данными.
Попытаемся кратко описать проблемы, которые видятся нам на этом пути. Во-первых, это проблема минимизации шифруемой информации. Требуется четко разделить служебную информацию и сами данные. От шифрования последних никуда не уйдешь, но служебную информацию можно либо не шифровать вообще, что практически возможно редко, т.к. служебная информация в большинстве случаев содержит индексы, которые могут нести полезную информацию, подлежащую шифрованию, либо шифровать ее частично. Методы шифрования в этих двух случаях могут принципиально различаться. Поскольку ЗАСУД должна обеспечивать быстрый доступ к единицам информации, наилучшим представляется блочное шифрование с размером блока, равным физическому размеру единицы информации в ЗАСУД. Более того, ЗАСУД должна обеспечивать выборку подмножества единиц информации, исходя из условий, задаваемых с помощью отношения порядка на множестве единиц информации. Для осуществления такой выборки без расшифрования шифр должен изоморфно переводить упорядоченное множество открытых единиц информации в упорядоченное множество шифрованных единиц информации. Естественно встает вопрос и о выборе оптимального размера блока — он важен как для скорости доступа к данным и минимизации занимаемого ими места, так и для защищенности данных шифром: чем короче блок, тем удобнее им оперировать, но при этом теряется стойкость блочного шифра.
КРИПТОГРАФИЧЕСКИЕ ПРОТОКОЛЫ ИДЕНТИФИКАЦИИ
В ЕДИНОЙ ИНФОРМАЦИОННОЙ ОБРАЗОВАТЕЛЬНОЙ СРЕДЕ
Т. И. Сенцова
Томский государственный университет
Одной из важнейших задач обеспечения безопасности единой информационной образовательной среды является разработка методов и средств, позволяющих одной (проверяющей) стороне (например, ресурсному центру) убедиться в идентичности другой (доказывающей) стороны (например, клиента). Широко распространенными механизмами решения данной проблемы являются специальные схемы (протоколы) идентификации, дающие возможность проверить корректность сообщений, которые демонстрируют, что доказывающий владеет определенным секретом. В простейших схемах идентификации в роли секрета выступает пароль. Одна из уязвимостей таких схем заключается в том, что после передачи доказывающим своего пароля проверяющему последний, используя данный пароль, в дальнейшем может выдать себя за проверяемого. Кроме того, пароли могут перехватываться или подбираться злоумышленником. Криптографические протоколы идентификации с нулевым разглашением лишены этих недостатков. В них проверяющий и доказывающий обмениваются многочисленными запросами и ответами, обычно зависящими от случайных чисел, посредством которых доказывающий убеждает проверяющего в знании своего секрета без разглашения какой-либо информации о самом секрете, кроме его размера..
Целью данной работы является исследование криптографических протоколов идентификации с нулевым разглашением Фейге-Фиата-Шамира (FFS), Гиллоу-Куискуотера (GQ) и Шнорра [1] по ряду эксплуатационных критериев, в том числе
1) коммуникационная эффективность — количество информации, передаваемой в процессе выполнения протокола для осуществления идентификации;
2) вычислительная эффективность — количество вычислительных операций, выполняемых сторонами в процессе идентификации по протоколу;
3) информационная эффективность — количество информации, необходимой для хранения секрета в протоколе;
4) реализационная эффективность — быстродействие (в единицах времени) программной реализации протокола.
Методы проведенных исследований — теоретический и экспериментальный: коммуникационная, вычислительная и информационная эффективность протоколов оцениваются аналитически, а реализационная — в компьютерном эксперименте путем моделирования протоколов в языке Visual C++ на PC. Для применения протоколов в сети Internet создано приложение <клиент-сервер> с использованием интерфейса сокетов. Полученные сравнительные оценки эффективности протоколов и их программных реализаций по указанным критериям позволяют осуществлять оптимальный выбор конкретного протокола идентификации для применения в конкретных условиях, т.е. в зависимости от технических и программных средств участвующих сторон (клиента и сервера).
В следующей таблице приведены расчетные оценки параметров эффективности данных протоколов для следующих значения их параметров (обозначения см. в [1]):
схема FFS — |n| = 512 бит, k = 20, t = 1;
схема GQ — |n| = 512 бит, |e| = 20 бит, t = 1;
схема Шнорра — |p| = 512 бит, |q| = 160 бит, |e| = 20 бит.
| Характеристики протоколов |
FFS
|
GQ
|
Shnorr
|
| Длина
открытого ключа |
1280 | 64 | 64 |
| Длина
секретного ключа |
1280 | 64 | 20 |
| Количество передаваемых байт | 131 | 131 | 87 |
| Количество модулярных умножений проверяющим | 11 | 30 | 54 |
| Количество модулярных умножений доказывающим | 11 | 30 | 49 |
Ниже дается качественное сравнение протоколов по перечисленным критериям.
Вычислительная эффективность. Для достижения того же уровня безопасности при использовании схемы GQ потребуется выполнить в три раза больше вычислений, чем в схеме FFS. При использовании схем идентификации в таких приложениях, как интеллектуальные карточки, основная проблема может возникнуть с выполнением модулярных умножений. С этой точки зрения предпочтение следует отдать схеме, основанной на факторизации — схеме FFS.
Коммуникационная эффективность. Протокол идентификации FFS минимизирует вычисления, увеличивая число итераций. Для ряда реализаций, например, для интеллектуальных карточек, это не слишком подходит. Обмены с внешним миром требуют времени, а хранение данных для каждой аккредитации может быстро исчерпать ограниченные возможности карточки. Преимуществом схемы идентификации Шнорра является снижение числа передаваемых бит и количество отправленных сообщений равно трем, тогда как в двух других схемах оно определяется значением 3t. Сокращается объем вычислений в реальном времени, что удобно для претендентов на идентификацию с ограниченными вычислительными возможностями.
Если на первом шаге протокола идентификации Шнорра вычисление значения x будет сделано предварительно, то количество модулярных умножений доказывающим снижается до одного. Такой интерактивный обмен информацией, полученной до начала идентификации возможен в некоторых приложениях. В остальных случаях рассматривается полное число модулярных умножений. Однако по сравнению с протоколами FFS и GQ, проверяющая сторона в схеме Шнорра требует существенных вычислительных возможностей.
Информационная эффективность. Схема FFS предъявляет самые большие требования к объему памяти для хранения секретной информации.
Предвычисления. Самым длительным этапом в работе протоколов является проведение предварительных вычислений, связанных с выбором системных параметров: генерация больших простых чисел, генерация пары простых чисел p и q таких, что p|q-1, нахождение элемента мультипликативной группы.
Время выполнения предварительных вычислений в протоколе FFS:
для |p| = 512 бит — до 2 мин.; для |p| = 1024 бит — до 8 мин.
Время выполнения предварительных вычислений в GQ-протоколе:
для |p| = 512 бит — до 1 мин.; для |p| = 1024 бит — до 7 мин..
Время выполнения предварительных вычислений в протоколе Шнорра для |p| = 512 бит, |q| = 160 бит — до 10 мин.
Время работы протоколов в секундах без учета проведенных предварительных вычислений показано в следующей таблице:
| Длина чисел в битах | FFS | GQ |
Shnorr|p| =512 |
||
| |n|=512 | |n|=1024 | |n|=512 | |n|=1024 | ||
| Время работы протокола (для 1000 запусков) | 22 | 178 | 159 | 363 | 579 |
Здесь время измерено при следующих значениях параметров протоколов:
схема FFS — t = 12, k = 5; схема GQ — t = 1, v = 32 бита; схема Шнорра — t = 60.
ЛИТЕРАТУРА
- Menezes A., van Oorschot P., and Vanstone S. Handbook of Applied Cryptography. — CRC Press, 1996. — www.cacr.math.uwaterloo.ca/hac
АНАЛИЗ БЕЗОПАСНОСТИ ПРОГРАММ, ЗАЩИЩЕННЫХ С ПОМОЩЬЮ КЛЮЧЕЙ HASP
В. Е. Шмелёв
Томский государственный университет
Данная работа посвящена теме защиты компьютерных программ от нелегального копирования с использованием программно-аппаратных средств защиты. В качестве таковых средств здесь рассматриваются аппаратные ключи. Метод защиты состоит в «привязывании» защищаемой программы к уникальному ключу, распространяемому вместе с программой. Ключи, как правило, подключаются к LPT-, USB-поpтам компьютера пользователя, и работоспособность программы зависит от присутствия этого ключа. Существует довольно большое число разновидностей таких ключей. В нашей стране наибольшей популярностью пользуются ключи HASP компании Aladdin Software Security R.D.[1]. Целью работы является изучить предоставляемые ключами этой фирмы возможности защиты программного обеспечения и рассмотреть некоторые уязвимости таких защит.
Ключи HASP предоставляют два различных метода защиты программ: автоматически — с использованием утилиты HASP Envelope, вручную — с помощью HASP API. Утилита HASP Envelopeпредназначена для защиты уже готовых программ без вмешательства в исходный код программы. При защите тело программы шифруется, в нее добавляется специальный модуль, который при запуске защищенной программы перехватывает управление и содержит специальные антиотладочные и антитрассировочные средства. API представляет собой мощнейший механизм защиты, посредством которого программа осуществляет вызовы функций обращения к ключу, маскируя их в теле программы или DLL. Функция API позволяет в любой момент проверять наличие ключа и предпринимать определённые шаги при его отсутствии. Главное назначение API — предоставление всего комплекса возможностей по защите программ, которыми обладает ключ.
Задачей для нас является заставить программу, защищенную HASP API или HASP Envelope, работать в условиях отсутствия легального ключа, подсоединенного к компьютеру. Любая защищенная программа состоит из самой программы и механизмов проверки ключа. Причем эти механизмы, как правило, не являются составными частями алгоритма самой программы, и их удаление не повлияет на работоспособность программы. Под удалением защитных механизмов здесь не всегда понимается удаление в прямом смысле, гораздо чаще требуется изменить их так, чтобы программа не обнаружила изменения, а сами механизмы при этом работали бы без ключа. В любой программе механизмами защиты являются некоторые функции, но, чтобы с ними разобраться, сначала их нужно найти, что не всегда является простой задачей в большом объеме кода. Существует несколько способов нахождения вызовов функций hasp().
Первый способ позволяет обнаруживать вызов hasp() по используемым этой функцией несекретным вспомогательным функциям. Одной из таких функций является FreeEnvironmentStringsA(), поэтому для обнаружения вызова функции hasp() ставим точку останова на обращение к функции FreeEnvironmentStringsA(). После того, как FreeEnvironmentStringsA() будет найдена, следует роверить, откуда она была вызвана, и решить, является ли функция, вызвавшая ее, функцией hasp() или это некоторая другая функция. Таким образом, данный метод позволяет сильно сократить число функций, подозрительных на то, чтобы являться функцией hasp().
Второй способ является более универсальным. Как бы функции hasp() ни прятались, в конечном счете вызов ключа это электрический сигнал, подаваемый на LPT-порт. Поскольку защита использует аппаратные средства, то и взлом может выполняться с применением тех же средств. Все, что необходимо для этого — несколько светодиодов, подключенных к LPT-порту, и любой отладчик, позволяющий выполнять пошаговую трассировку программы. Метод состоит в пошаговом проходе программы отладчиком без вхождения в процедуры до тех пор, пока не произойдет интересующее нас событие (вспышка светодиодов) во время выполнения одной из процедур, затем необходимо углубиться в эту процедуру и т.д. Этот метод здесь наиболее уместен ввиду того, что защитный механизм не может, как в случае чисто программной защиты, разделить во времени проверку условия и реакцию на нее.
Эти два способа позволяют обнаружить вызовы ключа, после чего работа ведется с самой программой, а именно с изменением ее реакции на отсутствие ключа.
Третий же способ работает с защитным механизмом. Не изменяя логики работы программы, он заставляет защитный механизм, не обращаясь к ключу, возвращать ожидаемые программой значения. Этот метод является универсальным как для защит с использованием HASP API, так и с использованием HASP Envelope. Он не требует нейтрализации множества ловушек для отладчика, присутствующих в теле программы. Это стало возможным благодаря тому, что точка входа в HASP API оставлена открытой. Отыскать ее просто: достаточно найти в тексте программы строку «HASPDOSDRV»; следующая за ней осмысленная команда, после некоторого количества незначащих байт, будет прыжком на то место, где происходит вызов функции. Все, что необходимо далее сделать, это — заменить найденный вызов функции на вызов функции, эмулирующей работу ключа.
Приведенный анализ позволяет сделать следующий вывод: защиту программ с помощью ключей HASP в существующем варианте вряд ли можно признать удовлетворительной.
Литература
- Руководство программиста HASP4/. Aladdin Knowledge Systems, 2002.
ПРОГРАММНАЯ РЕАЛИЗАЦИЯ КРИПТОГРАФИЧЕСКОГО ПРОТОКОЛА ЭЛЕКТРОННЫХ ДЕНЕГ В СЕТИ INTERNET
М. А. Михалева
Томский государственный университет
Сообщается о программной реализации криптографического протокола электронных денег, предназначенной для выполнения студентами лабораторной работы по курсу <Криптографические протоколы>.
Участниками рассматриваемого протокола являются: покупатель — Алиса, продавец — Боб и Банк. Предполагается, что Алиса и Боб имеют свои счета в Банке. Алиса желает рассчитаться с Бобом за некоторый товар электронной монетой (ЭМ). Для этого она создает ЭМ соответствующего номинала и обращается в Банк с просьбой подтвердить ее. Если средств на счете Алисы достаточно, Банк списывает указанную сумму и удовлетворяет ее просьбу. Алиса передает ЭМ Бобу в обмен на товар. Естественно, что Боб соглашается принять только подтвержденную Банком монету. Боб предъявляет ее в Банк, который, в свою очередь, проверив законность монеты, завершает торговую сделку зачислением денег в сумме, соответствующей номиналу ЭМ, на счет Боба. Целью криптографического протокола электронных денег является обеспечить безопасность каждого из участников этой сделки от возможного мошенничества со стороны других участников и стороннего наблюдателя Евы, а именно от следующих угроз:
— повторное предъявление монеты — использование Алисой или Бобом одной и той же ЭМ более одного раза;
— отслеживаемость — способность Евы или Банка (возможно, в сговоре с Бобом) установить, на что именно Алиса потратила выданную ей ЭМ.
Один из протоколов, достигающий этой цели и не требующий связи продавца с Банком в режиме on-line, предложен в работах Шаума и его коллег [1]. В нем под ЭМ понимается всякий набор M=(S, X, L1, L2, :, Lr), в котором S — номинал монеты, X — ее уникальный номер и для каждого j=1,2, :, r
Lj = (H(Ij0),(Ij0); H(Ij1),(Ij1)),
где Н — односторонняя хэш-функция, — симметричное шифрование по некоторому ключу kjb, известному только Алисе, и Ij0ÅIj1 = I — последовательность бит, идентифицирующая Алису в Банке, разделенная как секрет покомпонентным сложением по модулю 2 на две составляющие Ij0 и Ij1, одна из которых случайная. Таким образом, ЭМ не содержит в явном виде идентификатор Алисы, но в случае попытки повторного использования позволяет раскрыть личность мошенника.
Подлинность ЭМ подтверждается цифровой подписью Банка под ней, которая для обеспечения неотслеживаемости действий Алисы ставится вслепую. С этой целью ЭМ сначала маскируется путем умножения на некоторый маскирующий множитель, затем результат маскировки подписывается по некоторому алгоритму цифровой подписи и, наконец, с подписанной замаскированной монеты снимается маскировка.
В программной реализации данного протокола для шифрования составляющих идентификатора Алисы в ЭМ используется отечественный алгоритм ГОСТ 28147-89, их хэширование осуществляется функцией SHA1 и слепая подпись под монетой создается по алгоритму RSA. Подлинность сообщений, передаваемых участниками протокола по сети, и их источников контролируется посредством электронной цифровой подписи по схеме SHA1+RSA. Алгоритм RSA реализован с ключами длиной 1024 бит. Для этого создан класс больших чисел, позволяющий выполнять все необходимые арифметические операции и генерировать большие простые числа. Последнее осуществляется с использованием теста Миллера-Рабина. В рамках данного класса для генерации секретного ключа RSA реализован расширенный алгоритм Евклида, для более быстрого вычисления степени числа a по модулю n (ax mod n) используется бинарный метод. Из всех трех этапов протокола наиболее трудоемким оказывается этап генерации платежеспособной ЭМ, время работы которого существенно зависит от параметра безопасности m. Например, при m = 10 программа этого этапа требует до 2 мин. на компьютере с тактовой частотой 330 МГц.
Для удобства реализации протокола на языке C++ были созданы классы Coin, PrivateCoin, Key, Sign, IdentPair, предназначенные для работы со следующими объектами соответственно: электронная монета, секретная электронная монета (содержит маскирующий множитель и ключи шифрования ГОСТ), ключ ГОСТ, электронная цифровая подпись, пара составляющих идентификатора (Алисы).
На основе данного протокола создана электронная платежная система, состоящая из следующих подсистем:
Банк — выступает в роли эмитента электронной наличности;
Internet-магазин — предприятие, предоставляющее товары и/или услуги покупателям и принимающее к оплате электронные монеты;
Кошелек — средство для хранения электронных монет, автоматизации расчетов с Internet-магазином и перевода электронных денег с банковского счета в Кошелек и обратно.
Каждый участник протокола ведет свою базу данных: под управлением СУБД PostgreSQL — на стороне Банка и Internet-магазина, SQLite — на стороне покупателя.
Обмен информацией между банком, продавцом и клиентом осуществляется в соответствии с протоколом HTTP. Благодаря этому протоколу возможно применение стандартных информационных WWW-серверов (в частности, программного комплекса Apache). Для передачи данных от клиента к серверу используется метод POST, который дает возможность переслать на сервер большой объем данных. Протокол HTTP требует передачи информации в строковом виде, поэтому было предусмотрено преобразование данных, входящих в запрос, в шестнадцатеричную форму, и реализован обратный перевод в двоичный вид на стороне сервера.
Интерфейс между участниками протокола построен в соответствии с CGI — Common Gateway Interface, который является стандартом интерфейса внешней прикладной программы с WWW-сервером. Для взаимодействия с сервером (банком, продавцом) из основной программы, написанной на языке С++, на выполнение вызывается Tcl-скрипт, который формирует HTTP-запрос из данных, полученных от головной программы, отправляет его на сервер и получает ответ, результат обмена информацией с сервером передает в головную программу. На серверной стороне запросы клиентов обрабатываются соответствующим CGI-модулем, написанным на языке С++. CGI-программа выполняет действия, предусмотренные протоколом цифровых денег, и с помощью функций прикладного интерфейса СУБД PostgreSQL преобразует данные в SQL-запрос, устанавливает соединение с сервером СУБД и передает ему запрос на выполнение. Сервер СУБД выполняет запрос, обращаясь к базе данных, и возвращает результат CGI-программу, которая, в свою очередь, формирует HTML-документ и через сервер Apache передает его клиенту. На рис.1 приведена схема работы электронной платежной системы.
Рис. 1 Схема работы платежной системы
ПО продавца представлено программой send_to_bank.exe, запуская которую Internet-магазин переводит электронные монеты на банковский счет продавца.
Программное обеспечение клиента Кошелек работает под ОС Windows и Linux. Пользовательский интерфейс данной программы реализован на языке Tcl. Работоспособность программы тестировалась в следующей конфигурации компьютера клиента: Pentium 4, 1,8 Ггц, 256 Mb ОЗУ. Результаты тестирования следующие: получение монеты — не более 2 мин. (без маскировки — не более 20 сек.), проведение платежа — не более 8-9 сек., возврат монеты в банк — не более 12 сек.
Литература
Schneier B. Applied Cryptography, Second Edition. Protocols, Algorithms, and Source Code in C. — John Wiley & Sons, 1996.
К ВОПРОСУ РАЗРАБОТКИ КРИПТОПРОВАЙДЕРОВ В ОС WINDOWS
В. А. Мороцкий
Томский государственный университет
Криптопровайдер, или Cryptographic Service Provider (кратко — CSP), в ОС Windows — это библиотека криптографических алгоритмов, доступных прикладным программистам посредством интерфейса CryptoAPI (Cryptographic Application Programming Interface). При взаимодействии с CSP приложения вызывают функции CryptoAPI, которые обращаются к библиотекам Crypt32.dll и Advapi32.dll операционной системы. Последняя фильтрует вызовы этих функций и передаёт их далее соответствующим функциям CSP через CryptoSPI (Cryptographic System Program Interface).
Наряду со стандартными криптопровайдерами, поставляемыми Microsoft, можно использовать CSP собственной разработки, предварительно сертифицировав и подписав его в Microsoft.
Любой полноценный (с полным набором криптоалгоритмов) криптопровайдер обязательно должен экспортировать следующие функции: CPAcquireContext, CPCreateHash, CPDecrypt, CPDeriveKey, CPDestroyHash, CPDestroyKey, CPEncrypt, CPExportKey, CPGenKey, CPGenRandom, CPGetHashParam, CPGetKeyParam, CPGetProvParam, CPGetUserKey, CPHashData, CPHashSessionKey, CPImportKey, CPReleaseContext, CPSetHashParam, CPSetKeyParam, CPSetProvParam, CPSignHash, CPVerifySignatur. Криптопровайдер типа PROV_RSA_SCHANNEL или PROV_DH_SCHANNEL должен экспортировать также функции CPDuplicateHash и CPDuplicateKey.
Эти функции формируют системный программный интерфейс CryptoSPI, и каждая из них соответствует некоторой функции CryptoAPI. Все они должны быть объявлены с ключевым словом WINAPI. Их подробное описание можно посмотреть в MSDN [1].
Усеченный криптопровайдер может содержать часть перечисленных функций. Так, криптопровайдер mycspdll.dll с единственным криптоалгоритмом — MD5, разработанный автором в порядке самообучения, содержит только функции CPAcquireContext, CPReleaseContext, CPCreateHash, CPHashData, CPGetHashParam и CPDestroyHash. Он состоит из следующих трех модулей.
- Служебный модуль autoreg.cpp предназначен для регистрации CSP в ОС Windows. Он взят из пакета CSPDK (Cryptographic Service Provider Development Kit) с параметрами данного CSP.
- Модуль MD5Checksum.cpp содержит авторскую реализацию алгоритма хеширования MD5.
- Модуль mycspdll.cpp содержит шаблоны функций из пакета CSPDK, заполненные для указанных выше шести функций, относящихся к операции хеширования.
В действительности любой криптопровайдер состоит из собственно библиотеки CSP DLL и из файла цифровой подписи, который используется для проверки целостности криптопровайдера. Во время работы CryptoAPI периодически проверяет цифровую подпись под CSP DLL, чтобы исключить возможность подмены. Подпись может быть как встроенной (SigInFile), так и внешней (Signature). В ранних Windows были доступны только внешние подписи, которые размещались в соответствующем месте в реестре по ключу Signature и их можно было явно посмотреть. Начиная же с Windows 2000, стали доступны внутренние подписи, которые вставляются как ресурс в CSP DLL на этапе линковки. Применение внутренних подписей исключает возможность того, что подпись в реестре перестанет синхронизироваться с CSP DLL. Подробную информацию о том, как слинковать CSP DLL со встроенной подписью, можно посмотреть в соответствующих главах MSDN [1].
Для тестирования разработанных криптопровайдеров в пакет CSPDK входит утилита подписания cspSign.exe. Подпись, генерируемая этой утилитой, подходит лишь для отладочной версии Windows и на обычных системах не работает. Для обычной Windows нужна подпись от Microsoft, которую можно получить, послав свою CSP DLL по адресу cspsign@microsoft.com. Впрочем, можно <сломать> Advapi32.dll, и тогда подпись, генерируемая утилитой cspSign.exe, будет считаться правильной, что освободит Вас от необходимости посылать Ваш криптопровайдер в Microsoft. Более того, уже сломанные версии Advapi32.dll для Windows 2000, Windows 2000 SP1, Windows 2000 SP2 имеются в самом пакете CSPDK. Однако если Вы планируете писать свой криптопровайдер в Windows 2000 SP3 или в Windows XP и хотите избежать его подписания в Microsoft, то Вам придётся самостоятельно ломать файл Advapi32.dll. В случае c Windows XP для этого нужно поменять следующие 5 байт у библиотеки Advapi32.dll:
Address Origin Patch
00008794: 0F E9
00008795: 84 56
00008796: 55 14
00008797: 14 02
00008798: 02 00
Для тестирования CSP в Windows 2000 SP3 и выше можно использовать отладчик ядра (kernel debugger), который поставляется вместе с пакетом DDK, т.к. при запущенном отладчике ядра подпись под CSP DLL не проверяется.
При подписании своего CSP автор использовал встроенную подпись, для чего потребовалось проделать следующую последовательность действий:
- создать файл подписи mycspdll.sig и подключить его ко всему проекту CSP;
- открыть его с помощью редактора бинарных ресурсов, заполнить нулями и в результате получить пустой файл mycspdll.sig размером 144 байта;
- подключить к проекту ресурс mycspdll.rc, который должен обязательно содержать строку CRYPT_SIG_RESOURCE_NUMBER Rcdata DISCARDABLE «mycspdll.sig«;
- при первой компиляции и линковке проекта получить на выходе файл mycspdll.dll и подписать его утилитой cspSign.exe следующим образом: cspSign.exe c mycspdll.dll mycspdll.sig
- затем осуществить повторную сборку проекта и на выходе получить CSP DLL под именем mycspdll.dll, которая уже содержит встроенную подпись.
Для проверки разработанного CSP написано тестовое Win32-приложение, в котором для обращения к функциям CSP используются их Crypt_ аналоги. Функциями Crypt_ из тестового приложения программист обращается к библиотеке Advapi32.dll, которая по параметрам вызова находит нужный криптопровайдер, а затем вызывает соответствующие CP_ функции данного CSP. В заключение выражаю благодарность А.А. Скутину за постановку задачи.
Литература
- MSDN Library (http://www.msdn.microsoft.com)