WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 4 | 5 ||

«О.В. КАЗАРИН Москва 2004 УДК 681.322 Казарин О.В. ...»

-- [ Страница 6 ] --

Таким образом, при таком определении семейства функций F, не существует способов обфускации программ при вычислении F, даже если обфускация предназначена для сокрытия лишь одного бита информации об этой функции (т.е. (f)) и даже если обфускатор имеет неограниченное время вычислений.

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

Этот результат о теоретической невозможности полной обфускации расширен различными путями, включая обфускаторы, которые: (a) не обязательно вычисляют за полиномиальное время, (б) только приблизительно сохраняют функциональные возможности (аппроксимирующие обфускаторы) и (в) должны работать только для очень ограниченных моделей вычислений.

12.4.3. Практические вопросы построения обфускаторов Рассмотрим пример исходного псевдокода некоторой программы перед обфускацией (см. рис.12.1.). Можно попытаться понять, каков результат обфускации приведенной программы (см. рис.12.2). Для этого надо узнать, что за классы принимают участие в работе программы, попробовать понять их назначение. В большинстве случаев - это достаточно большой труд.

private void CalcPayroll(SpecialList employeeGroup) { while(employeeGroup.HasMore()) { employee = employeeGroup.GetNext(true);

employee.UpdateSalary();

DistributeCheck(employee);

} } Рис. 12.1. Псевдокод программы до обфускации private void _1(_1 _2) { while(_2._1()) { _1 = _2._1(true);

_1._1();

_1(_1);

} } Рис. 12.2. Псевдокод программы после обфускации Таким образом, задача обфускации заключается, как это видно из рис. 12.1.-12.2., в затруднении для понимания и анализа исходного кода программы, запутывании и устранении логических связей в этом коде.

Основные функции при обфускации программ, например, для.Net сборок могут заключаться в следующем. Сначала анализируются метаданные, так как не все члены сборки обфускатор может обработать.

Например, обфускатору не стоит заменять имена конструкторов типа данных – это может привести к нежелательным последствиям. Хотя в некоторых случаях это возможно.

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

После этого производится запись данных обратно в сборку или генерация новой сборки, ее оптимизация – так как многие из обфускаторов способны удалять ненужную информацию из сборки (отладочную информацию, неиспользуемые поля, классы и т.п.). Таким образом, сборка после обфускации готова и мы получаем обфуцированную программу.

ГЛАВА 13. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ ЦЕЛОСТНОСТИ И ДОСТОВЕРНОСТИ ИСПОЛЬЗУЕМОГО ПРОГРАММНОГО КОДА 13.1. МЕТОДЫ ЗАЩИТЫ ПРОГРАММ ОТ НЕСАНКЦИОНИРОВАННЫХ ИЗМЕНЕНИЙ Решение проблемы обеспечения целостности и достоверности электронных данных включает в себя решение, по крайней мере, трех основных взаимосвязанных задач: подтверждения их авторства и подлинности, а также контроль целостности данных. Решение этих трех задач в случае защиты программного обеспечения вытекает из необходимости защищать программы от следующих злоумышленных действий:

• РПС могут быть внедрены в авторскую программу или эта программа может быть полностью заменена на программу-носитель РПС;

• могут быть изменены характеристики (атрибуты) программы;

• злоумышленник может выдать себя за настоящего владельца программы;

• законный владелец программы может отказаться от факта правообладания ею.

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

Так как область значений, например, контрольной суммы сильно ограничена, а значения функции контроля на четность вообще представляются одним-двумя битами, то для опытного нарушителя не составляет труда найти следующую коллизию: f(k1)=f(k2), где k1 - код программы без внесенной нарушителем закладки, а k2 - с внесенной программным закладкой и f - функция контроля. В этом случае значения функции для разных аргументов совпадают при тестировании и, следовательно, РПС обнаружено не будет.

Для установления подлинности (неизменности) программ необходимо использовать более сложные методы, такие как аутентификация кода программ, с использованием криптографических способов, которые обнаруживают следы, остающиеся после внесения преднамеренных искажений.

В первом случае аутентифицируемой программе ставится в соответствие некоторый аутентификатор, который получен при помощи стойкой криптографической функции. Такой функцией может быть криптографически стойкая хэш-функция (например, функция ГОСТ Р 34.11-94) или функция электронной цифровой подписи (например, функция изГОСТ Р 34.10-94). И в том, и в другом случае аргументами функции может быть не только код аутентифицируемой программы, но и время и дата аутентификации, идентификатор программиста и/или предприятия - разработчика ПО, какой-либо случайный параметр и т.п.

Может использоваться также любой симметричный шифр (например, DES или ГОСТ 28147-89) в режиме генерации имитовставки. Однако это требует наличия секретного ключа при верификации программ на целостность, что бывает не всегда удобно и безопасно. В то время как при использовании метода цифровой подписи при верификации необходимо иметь только некоторую общедоступную информацию, в данном случае открытый ключ подписи. То есть контроль целостности ПО может осуществить любое заинтересованное лицо, имеющее доступ к открытым ключам используемой схемы цифровой подписи.

Подробные справочные данные и технические детали криптографических методов, применяемых, в том числе, и для защиты ПО рассмотрены в приложении.

Можно еще более усложнить действия злоумышленника по нарушению целостности целевых программ, используя схемы подписи с верификацией по запросу [Ка5,ка14]. В этом случае тестирование программ по ассоциированным с ними аутентификаторам можно осуществить только в присутствии лица, сгенерировавшего эту подпись, то есть в присутствии разработчика программ или представителей предприятия-изготовителя программного обеспечения. В этом случае, если даже злоумышленник и получил для данной программы некий аутентификатор, то ее обладатель может убедиться в достоверности программы только в присутствии специалистов-разработчиков, которые немедленно обнаружат нарушения целостности кода программы и (или) его подлинности.

Комбинация схем подписи и интерактивных систем доказательств позволила создать схемы подписи с верификацией по запросу. Такие схемы используются для обеспечения целостности и достоверности программно обеспечения.

13.2. СХЕМА ПОДПИСИ С ВЕРИФИКАЦИЕЙ ПО ЗАПРОСУ В работах Д. Шаума (см., например, [Ка5,Ка14]) впервые была предложена схема подписи с верификацией по запросу, в которой абонент V не может осуществить верификацию подписи без участия абонента S.

Такие схемы могут эффективно использоваться в том случае, когда фирма - изготовитель поставляет потребителю некоторый информационный продукт (например, программное обеспечение) с проставленной на нем подписью указанного вида [КУ10]. Однако проверить эту подпись, которая гарантирует подлинность программы или отсутствие ее модификаций, можно только уплатив за нее. После факта оплаты фирма - изготовитель дает разрешение на верификацию корректности полученных программ.

Схема состоит из трех этапов (протоколов), к которым относятся непосредственно этап генерации подписи, этап верификации подписи с обязательным участием подписывающего (протокол верификации) и этап оспаривания, если подпись или целостность подписанных сообщений подверглась сомнению (отвергающий протокол).

Схема ПВЗ Пусть каждый пользователь S имеет один открытый ключ P и два секретных ключа S1 и S2. Ключ S1 всегда остается в секрете, - он необходим для генерации подписи. Ключ S2 может быть открыт для того, чтобы конвертировать схему подписи с верификацией по запросу в обычную схему электронной цифровой подписи.

Вместе с обозначениями секретного и открытого ключей xRZq и yRZ*p (взятых из отечественного стандарта на электронную цифровую подпись) введем также обозначения S1=x и S2=u, uRZq, а также открытый ключ P=(g,y,w), где wgu(mod p).

Открытый ключ P публикуется в открытом сертифицированном справочнике.

Протокол ГП Подпись кода m вычисляется следующим образом.

k r g (mod p) Выбирается kRZq и вычисляется. Затем вычисляется s[xr+mku](mod q). Пара (r,s) является подписью для кода m. Подпись считается корректной тогда и только тогда, sw ru g y-rw(mod p) когда, где wm-1(mod q).

Проверка подписи (с участием подписывающего) осуществляется посредством следующего интерактивного протокола.

Протокол верификации ПВ sw g y-rw(mod p) Абонент V вычисляет и просит абонента S доказать, что пара (r,s) есть его подпись под кодом m.

Эта задача эквивалентна доказательству того, что дискретный логарифм по основанию r равен (по модулю p) дискретному логарифму w по основанию g, то есть, что logg(p)wlogr(p). Для этого:

a b r g (mod p) 1. Абонент V выбирает a,bRZq, вычисляет и посылает абоненту S.

t h1 g (mod p) 2. Абонент S выбирает tRZq, вычисляет, h2 h1u (mod p) и посылает h1 и h2 абоненту V.

3. Абонент V высылает параметры a и b.

ra gb (mod p) 4. Если, то абонент S посылает V параметр t;

в противном случае - останавливается.

5. Абонент V проверяет выполнение равенств a h1 ra gb+t (mod p) h2 wb+t (mod p) и.

Если проверка завершена успешно, то подпись принимается как корректная.

Протокол ОП В отвергающем протоколе S доказывает, что logg(p)wlogr(p).

Следующие шаги выполняются в цикле l раз.

1. Абонент V выбирает d,eRZq, d1, R{0,1}. Вычисляет e a g (mod p) b we(mod p) a re(mod p),, если =0 и, e b (mod p), если =1. Посылает S значения a, b, d.

au (mod p) b 2. Абонент S проверяет соотношение. Если оно выполняется, то =0, в противном случае =1. Выбирает R c d g (mod p) RRZq, вычисляет и посылает V значение c.

3. Абонент V посылает абоненту S значение e.

4. Абонент S проверяет, что выполняются соотношения из a ge (mod p) b we (mod p) следующих двух их пар:, и e a re (mod p) b (mod p),. Если да, то посылает V значение R.

Иначе останавливается.

R d g (mod p) с 5. Абонент V проверяет, что.

Если во всех l циклах проверка в п.5 выполнена успешно, то абонент V принимает доказательства.

Таблица 13.1. Протокол верификации является интерактивным протоколом доказательств с абсолютно нулевым разглашением.

Доказательство. Требуется доказать, что вышеприведенный протокол удовлетворяет трем свойствам: полноты, корректности и нулевого разглашения [Ка5, Ка14].

Полнота означает, что если оба участника (V и S) следуют протоколу и (r,s) - корректная подпись для сообщения m, то V примет доказательство с вероятностью близкой к 1. Из описания протокола верификации очевидно, что абонент S всегда может надлежащим образом ответить на запросы абонента V, то есть доказательство будет принято с вероятностью 1.

Корректность означает, что если V действует согласно протоколу, то какие действия не предпринимал бы S, он может обмануть V лишь с пренебрежимо малой вероятностью. Здесь под обманом понимается попытка S доказать, что logg(p)wlogr(p), когда на самом деле эти логарифмы не равны.

Предположим, что logg(p)wlogr(p). Ясно, что для каждого a существует единственное значение b, то которое дает данный запрос.

Поэтому не содержит в себе никакой информации об a. Если S смог бы найти h1, h2, t1 и t2 такие, что 1 1 2 h1 ra gb +t1 ra gb +t2 (mod p) и a1 1 a2 h2 wb +t1 wb +t1 (mod p), где a1a2, то тогда выполнялось бы соотношение logg(p)r[(a1-a2)-1((b2-b1)+(t2-t1))](mod q)logw(p).

Отсюда, очевидно, следует, что logg(p)wlogr(p). В самом деле, пусть logw(p)logg(p)r. Тогда ( p ) ( p ) log w g g w g rlog w (mod p), что противоречит предположению. Следовательно, какие бы h1, h2, t1 и t не выбрал S, проверка, которую проводит V, может быть выполнена только для одного значения a. Отсюда вероятность обмана не превосходит 1/q.

Отметим, что протокол верификации является безусловно стойким для абонента V, то есть доказательство корректности не зависит ни от каких предположений о вычислительной мощности доказывающего (S).

Свойство нулевого разглашения означает, что в результате выполнения протокола абонент V не получает никакой полезной для себя информации (например, о секретных ключах, используемых S). Для доказательства нулевого разглашения необходимо для любого возможного проверяющего V* построить моделирующую машину M, которая * V является вероятностной машиной Тьюринга, работает за полиномиальное в среднем время и создает на выходе (без участия S) такое же распределение случайных величин, которое возникает у V* в результате выполнения протокола. В нашем случае, случайные величины, которые «видит» V*, - это h1, h2, и t. Необходимо доказать, что протокол верификации является доказательством с абсолютно нулевым разглашением, то есть моделирующая машина создает распределение случайных величин (h1,h2,t), которое в точности совпадает с их распределением, возникающим при MV выполнении протокола. Моделирующая машина использует в своей * работе V* в качестве «черного ящика».

Моделирующая машина 1. Запоминает состояние машины V*, то есть содержимое всех ее лент, внутреннее состояние и позиции головок на лентах.

Затем получает от V* значение и после этого снова запоминает состояние машины V*.

h1 g (modp) 2. Выбирает RZq и вычисляет и h2 r (mod p).

ra gb (mod p) 3. Получает от V* значения a и b. Если, то MV останавливается.

* MV 4. Машина «отматывает» V* на состояние, которое * было запомнено в конце шага 1. Выбирает tRZq и вычисляет a h1 ragb+t (mod p) h2 wb+t (mod p) и.

MV 5. Машина передает V* h1, h2 и получает ответ (a,b).

* Возможны два варианта:

5.1. a=a, b=b. В этом случае моделирование закончено MV и записывает на выходную ленту тройку (h1,h2,t) и * останавливается.

5.2. aa или bb. Отсюда следует, что ra gb ragb (mod p). Предположим, что bb. Из этого M следует, что aa. Следовательно, может вычислить * V -b) r g(b /(a-a) (mod p). Отсюда (b-b)/(a-a)=l - дискретный логарифм r по основанию g.

M 6. Машина * «отматывает» V* на состояние, которое V было заполнено в начале шага 1. Получает от V* значение.

h1 g (mod p) 7. Выбирает RZq вычисляет и h2 w (mod p) и передает их V*.

a b r g (mod p) 8. Получает от V* значения a и b. Если, то M * останавливается. В противном случае вычисляет V t=[-al-b](mod q), выдает (h1,h2,t) на выходную ленту и останавливается.

К пп. 7 и 8 необходимо сделать следующее пояснение. Поскольку logg(p)wlogr(p), из этого следует, что logw(p)logg(p)r. Отсюда a h2 w wb+t wal wb+t (mod p).

M Из описания моделирующей машины * очевидно, что она V работает за полиномиальное время. Величины (h1,h2,t) на шаге 5. выбираются в точности как в протоколе и поэтому имеют такое же распределение вероятностей. Кроме того, значения (h1,h2), выбираемые на шаге 7, имеют такое же распределение, как и в протоколе. Чтобы показать что и t имеет одинаковое распределение, достаточно заметить, что машина M V* не может по h1 и h2 определить, с кем она имеет дело - с S или *.

V Поэтому, даже если бы V* могла каким-либо «хитрым» образом строить a и b с учетом (h1,h2), распределение вероятностей величин a и b в обоих случаях одинаковы. Но значение t определяется однозначно четверкой величин a, b, h1, h2, при условии выполнения проверки на шаге протокола. Таблица 13.2. Отвергающий протокол является протоколом доказательства с абсолютно нулевым разглашением.

Доказательство. Полнота протокола очевидна. Если абоненты S и V следуют протоколу, тогда абонент V всегда примет доказательства абонента S.

Для доказательства корректности прежде всего заметим, что если logg(p)wlogr(p), то a и b, выбираемые абонентом V на шаге 1, не несут в себе никакой информации о значении. Поэтому, если S может “открыть” c, сгенерированное им на шаге 2, лишь единственным образом (то есть выдать на шаге 4 единственное значение R, соответствующее данному ), то проверка на шаге 5 будет выполнена с вероятностью 1/2 в одном цикле и с вероятностью 1/2l во всех l циклах.

Если же S может сгенерировать c таким образом, что с вероятностью, которая не является пренебрежимо малой, он может на шаге 4 “открыть” R c dg (mod p) оба значения, то есть найти R1 и R2 такие, что и R c g (mod p), то алгоритм, который использует S для этой цели, можно использовать для вычисления дискретных логарифмов: loggd=R2-R1. Так как при случайном выборе значения d логарифм loggd может быть вычислен с вероятностью, которая не является пренебрежимо малой, это противоречит гипотезе о трудности вычисления дискретных логарифмов.

Далее доказывается, что отвергающий протокол является доказательством с абсолютно нулевым разглашением. Для этого необходимо для всякого возможного проверяющего V* построить моделирующую машину M, которая создает на выходе (без участия S) * V такое же распределение случайных величин (в данном случае, c и R), какое возникает у V* в результате выполнения протокола.

Моделирующая машина Следующие шаги выполняются в цикле l раз.

M 1. Машина * запоминает состояние машины V*.

V 2.Получает от V* значения a, b и d.

R c d g (mod p) 3.Выбирает R{0,1}, RRZq и вычисляет.

Посылает V* значение c.

4.Получает от V* значение e.

5.Проверяет, было ли «угадано» на шаге 2 значение (это e a g (mod p) b we (mod p) значение было «угадано», если, и e a re (mod p) b (mod p) =1). Если да, то =0, либо, и записывает на входную ленту значение (c,R). В противном случае «отматывает» V* на то состояние, которое было запомнено на шаге 1, и переходит на шаг 2.

Легко видеть, что распределения случайных величин (c,R), возникающее в процессе выполнения протокола и создаваемые M моделирующей машиной *, одинаковы, поскольку R в обоих случаях - V чисто случайная величина, а величина c записывается на выходную ленту M машины * только тогда, когда совпало с.

V M Поскольку значение выбирается машиной * на шаге V случайным образом, а c не дает V* никакой информации о значении, на каждой итерации будет угадано с вероятностью 1/2. Отсюда следует, что M машина * работает за полиномиальное в среднем время. V В работе [Ка14] показано, как строить схемы конвертируемой и селективно конвертируемой подписи с верификацией по запросу на основе отечественного стандарта ГОСТ Р 34.10-94. В таких схемах открытие определенного секретного параметра некоторой схемы подписи с верификацией по запросу позволяет трансформировать последнюю в обычную схему цифровой подписи. При этом открытие секретного параметра в конвертируемой схеме подписи с верификацией по запросу дает возможность верифицировать все имеющиеся и сгенерированные в дальнейшем подписи, в то время как в селективно конвертируемых схемах подписи с верификацией по запросу можно верифицировать лишь какую либо одну подпись.

13.3. ПРИМЕРЫ ПРИМЕНЕНИЯ СХЕМЫ ПОДПИСИ С ВЕРИФИКАЦИЕЙ ПО ЗАПРОСУ Предположим фирма-изготовитель программного обеспечения распространяет свою продукцию посредством электронной почты. На каждом экземпляре ПО проставляется некоторая подпись (тип подписи пока не определен, но в любом случае подпись представляет собой значение функции, аргументами которой обязательно являются подписываемые данные и секретный ключ подписывающего). Эта подпись гарантирует, что программы являются подлинными (то есть, разработаны фирмой-изготовителем) и не были модифицированы. Однако верифицировать эту подпись, можно только уплатив за программный продукт. В этом случае фирма - изготовитель во взаимодействии с потребителем устанавливают корректность подписи, а значит и подлинность проданных программ.

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

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

Особенности реализации подобных сценариев, а также злоумышленные действия в отношении предлагаемых схем защиты, рассмотрены в работах [КУ10,Ка5,Ка14].

Напомним, что все необходимые сведения об алгоритмах криптографического преобразования данных, в том числе и в целях защиты программ, а также другие сведения из криптографии и криптоанализа, приведены в приложении.

ГЛАВА 14. ОСНОВНЫЕ ПОДХОДЫ К ЗАЩИТЕ ПРОГРАММ ОТ НЕСАНКЦИОНИРОВАННОГО КОПИРОВАНИЯ 14.1. ОСНОВНЫЕ ФУНКЦИИ СРЕДСТВ ЗАЩИТЫ ОТ КОПИРОВАНИЯ При защите программ от несанкционированного копирования применяются методы, которые позволяют привносить в защищаемую программу функции привязки процесса выполнения кода программы только на тех ЭВМ, на которые они были инсталлированы.

Инсталлированная программа для защиты от копирования при каждом запуске должна выполнять следующие действия:

• анализ аппаратно-программной среды компьютера, на котором она запущена, формирование на основе этого анализа текущих характеристик своей среды выполнения;

• проверка подлинности среды выполнения путем сравнения ее текущих характеристик с эталонными, хранящимися на винчестере;

• блокирование дальнейшей работы программы при несовпадении текущих характеристик с эталонными.

Этап проверки подлинности среды является одним из самых уязвимых с точки зрения защиты. Можно детально не разбираться с логикой защиты, а немного «подправить» результат сравнения, и защита будет снята.

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

Для снятия защиты от копирования применяют два основных метода:

статический и динамический [РД].

Статические методы предусматривают анализ текстов защищенных программ в естественном или преобразованном виде. Динамические методы предусматривают слежение за выполнением программы с помощью специальных средств снятия защиты от копирования.

14.2. ОСНОВНЫЕ МЕТОДЫ ЗАЩИТЫ ОТ КОПИРОВАНИЯ 14.2.1. Криптографические методы Для защиты инсталлируемой программы от копирования при помощи криптографических методов инсталлятор программы должен выполнить следующие функции:

• анализ аппаратно-программной среды компьютера, на котором должна будет выполняться инсталлируемая программа, и формирование на основе этого анализа эталонных характеристик среды выполнения программы;

• запись криптографически преобразованных эталонных характеристик аппаратно-программной среды компьютера на винчестер.

Преобразованные эталонные характеристики аппаратно-программной среды могут быть занесены в следующие области жесткого диска:

• в любые места области данных (в созданный для этого отдельный файл, в отдельные кластеры, которые должны помечаться затем в FAT как зарезервированные под операционную систему или дефектные);

• в зарезервированные сектора системной области винчестера;

• непосредственно в файлы размещения защищаемой программной системы, например, в файл настройки ее параметров функционирования.

Можно выделить два основных метода защиты от копирования с использованием криптографических приемов:

• с использованием односторонней функции;

• с использованием шифрования (которое также может использовать односторонние функции).

Односторонние функции это функции, для которых при любом x из области определения легко вычислить f(x), однако почти для всех y из ее области значений, найти y=f(x) вычислительно трудно (см. приложение).

Если эталонные характеристики программно-аппаратной среды представить в виде аргумента односторонней функции x, то y - есть «образ» этих характеристик, который хранится на винчестере и по значению которого вычислительно невозможно получить сами характеристики. Примером такой односторонней функции может служить функция дискретного экспоненцирования, описанная ранее, с размерностью операндов не менее 512 битов.

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

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

Основным требованием к записанному на винчестер уникальному идентификатору является требование, согласно которому данный идентификатор не должен копироваться стандартным способом. Для этого идентификатор целесообразно записывать в следующие области жесткого диска:

• в отдельные кластеры области данных, которые должны помечаться затем в FAT как зарезервированные под операционную систему или как дефектные;

• в зарезервированные сектора системной области винчестера.

Некопируемый стандартным образом идентификатор может помещаться на дискету, к которой должна будет обращаться при каждом своем запуске программа. Такую дискету называют ключевой. Кроме того, защищаемая от копирования программа может быть привязана и к уникальным характеристикам ключевой дискеты. Следует учитывать, что при использовании ключевой дискеты значительно увеличивается неудобство пользователя, так как он всегда должен вставлять в дисковод эту дискету перед запуском защищаемой от копирования программы.

14.2.3. Методы, основанные на работе с переходами и стеком Данные методы основаны на включение в тело программы переходов по динамически изменяемым адресам и прерываниям, а также самогенерирующихся команд (например, команд, полученных с помощью сложения и вычитания). Кроме того, вместо команды безусловного перехода (JMP) может использоваться возврат из подпрограммы (RET).

Предварительно в стек записывается адрес перехода, который в процессе работы программы модифицируется непосредственно в стеке.

При работе со стеком, стек определяется непосредственно в области исполняемых команд, что приводит к затиранию при работе со стеком.

Этот способ применяется, когда не требуется повторное исполнение кода программы. Таким же способом можно генерировать исполняемые команды до начала вычислительного процесса.

14.2.4. Манипуляции с кодом программы При манипуляциях с кодом программы можно привести два следующих способа:

• включение в тело программы «пустых» модулей;

• изменение защищаемой программы.

Первый способ заключается во включении в тело программы модулей, на которые имитируется передача управления, но реально никогда не осуществляется. Эти модули содержат большое количество команд, не имеющих никакого отношения к логике работы программы. Но «ненужность» этих программ не должна быть очевидна потенциальному злоумышленнику.

Второй способ заключается в изменении начала защищаемой программы таким образом, чтобы стандартный дизассемблер не смог ее правильно дизассемблировать. Например, такие программы, как Nota и Copylock, внедряя защитный механизм в защищаемый файл, полностью модифицируют исходный заголовок EXE-файла.

Все перечисленные методы были, в основном направлены на противодействия статическим способам снятия защиты от копирования. В следующем подразделе рассмотрим методы противодействия динамическим способам снятия защиты.

14.2.5. Методы противодействия динамическим способам снятия защиты программ от копирования Набор методов противодействия динамическим способам снятия защиты программ от копирования включает следующие методы [РД]:

• периодический подсчет контрольной суммы, занимаемой образом задачи области оперативной памяти, в процессе выполнения. Это позволяет:

- заметить изменения, внесенные в загрузочный модуль;

- в случае если программу пытаются «раздеть», выявить контрольные точки, установленные отладчиком;

• проверка количества свободной памяти и сравнение и с тем объемом, к которому задача «привыкла» или «приучена». Это действия позволит застраховаться от слишком грубой слежки за программой с помощью резидентных модулей;

• проверка содержимого незадействованных для решения защищаемой программы областей памяти, которые не попадают под общее распределение оперативной памяти, доступной для программиста, что позволяет добиться «монопольного» режима работы программы;

• проверка содержимого векторов прерываний (особенно 13h и 21h) на наличие тех значений, к которым задача «приучена». Иногда бывает полезным сравнение первых команд операционной системы, отрабатывающих этим прерывания, с теми командами, которые там должны быть. Вместе с предварительной очисткой оперативной памяти проверка векторов прерываний и их принудительное восстановление позволяет избавиться от большинства присутствующих в памяти резидентных программ;

• переустановка векторов прерываний. Содержимое некоторых векторов прерываний (например, 13h и 21h) копируется в область свободных векторов. Соответственно изменяются и обращения к прерываниям. При этом слежение за известными векторами не даст желаемого результата. Например, самыми первыми исполняемыми командами программы копируется содержимое вектора 21h ( байта) в вектор 60h, а вместо команд int 21h в программе везде записывается команда int 60h. В результате в явном виде в тексте программы нет ни одной команды работы с прерыванием 21h;

• постоянное чередование команд разрешения и запрещения прерывания, что затрудняет установку отладчиком контрольных точек;

• Контроль времени выполнения отдельных частей программы, что позволяет выявить «остановы» в теле исполняемого модуля.

Многие перечисленные защитные средства могут быть реализованы исключительно на языке Ассемблер. Одна из основных отличительных особенностей этого языка заключается в том, что для него не существует ограничений в области работы со стеком, регистрами, памятью, портами ввода/вывода и т.п.

ГЛАВА 15. ПРАВОВАЯ И ОРГАНИЗАЦИОННАЯ ПОДДЕРЖКА ПРОЦЕССОВ РАЗРАБОТКИ И ПРИМЕНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ЧЕЛОВЕЧЕСКИЙ ФАКТОР 15.1. СТАНДАРТЫ И ДРУГИЕ НОРМАТИВНЫЕ ДОКУМЕНТЫ, РЕГЛАМЕНТИРУЮЩИЕ ЗАЩИЩЕННОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ОБРАБАТЫВАЕМОЙ ИНФОРМАЦИИ 15.1.1. Международные стандарты в области информационной безопасности Общие вопросы За рубежом разработка стандартов проводится непрерывно, последовательно публикуются проекты и версии стандартов на разных стадиях согласования и утверждения. Некоторые стандарты поэтапно углубляются и детализируются в виде совокупности взаимосвязанных по концепциям и структуре групп стандартов.

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

Разработка стандартов для открытых систем, в том числе и стандартов в области безопасности ИТ, осуществляется рядом специализированных международных организаций и консорциумов таких, как, например, ISO, IЕС, ITU-T, IEEE, IАВ, WOS, ЕСМА, X/Open, OSF, OMG и др. [Су].

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

Архитектура безопасности Взаимосвязи открытых систем Большинство современных сложных информационных структур, лежащих в качестве основы существующих АС проектируются с учетом идеологии Эталонной модели (ЭМ) Взаимосвязи открытых систем (ВОС), которая позволяет оконечному пользователю сети (или его прикладным процессам) получить доступ к информационно-вычислительным ресурсам значительно легче, чем это было раньше. Вместе с тем концепция открытости систем создает ряд трудностей в организации защиты информации в системах и сетях. Требование защиты ресурсов сети от НСД является обязательным при проектировании и реализации большинства современных информационно-вычислительных сетей, соответствующих ЭМ ВОС.

В 1986 г. рядом международных организаций была принята Архитектура безопасности ВОС (АБ ВОС). В архитектуре ВОС выделяют семь уровней иерархии: физический, канальный, сетевой, транспортный, сеансовый, представительный и прикладной. Однако в АБ ВОС предусмотрена реализация механизмов защиты в основном на пяти уровнях. Для защиты информации на физическом и канальном уровне обычно вводится такой механизм защиты, как линейное шифрование.

Канальное шифрование обеспечивает закрытие физических каналов связи с помощью специальных шифраторов. Однако применение только канального шифрования не обеспечивает полного закрытия информации при ее передаче по сети, так как на узлах коммутации пакетов информация будет находиться в открытом виде. Поэтому НСД нарушителя к аппаратуре одного узла ведет к раскрытию всего потока сообщений, проходящих через этот узел. В том случае, когда устанавливается виртуальное соединение между двумя абонентами сети и коммуникации, в данном случае, проходят по незащищенным элементам сети, необходимо сквозное шифрование, когда закрывается информационная часть сообщения, а заголовки сообщений не шифруются. Это позволяет свободно управлять потоками зашифрованных сообщений. Сквозное шифрование организуется на сетевом и/или транспортном уровнях согласно ЭМ ВОС. На прикладном уровне реализуется большинство механизмов защиты, необходимых для полного решения проблем обеспечения безопасности данных в ИВС.

АБ ВОС устанавливает следующие службы безопасности (см.

табл.15.1).

• обеспечения целостности данных (с установлением соединения, без установления соединения и для выборочных полей сообщений);

• обеспечения конфиденциальности данных (с установлением соединения, без установления соединения и для выборочных полей сообщений);

Таблица 15. Назначение службы Номер Процедура защиты Номер службы уровня Аутентификация:

Одноуровневых 1 Шифрование, цифровая подпись 3, объектов Обеспечение аутентификации 3,4, Шифрование 3, источника данных 2 Цифровая подпись 3,4, Контроль доступа 3 Управление доступом 3,4, Засекречивание:

соединения 4 Шифрование 1-4,6, Управление трафиком в режиме без соединения 5 Шифрование 2-4,6, Управление трафиком выборочных полей 6 Шифрование 6, потока данных Шифрование 1, 7 Заполнение потока 3, Управление трафиком Обеспечение целостности:

соединения с 8 Шифрование, обеспечение 4, восстановлением целостности данных 9 Шифрование, обеспечение 3,4, соединения без целостности данных восстановления 10 Шифрование, обеспечение целостности данных выборочных полей 11 Шифрование 3,4, Цифровая подпись без установления Обеспечение целостности 3,4, соединения 12 данных Шифрование Цифровая подпись 4, выборочных полей без Обеспечение целостности соединения данных Обеспечение невозможности отказа от факта:

отправки 13 Цифровая подпись, обеспечение целостности данных, подтверждение характеристик данных доставки 14 Цифровая подпись, обеспечение целостности данных, подтверждение характеристик данных • контроля доступа;

• аутентификации (одноуровневых объектов и источника данных);

• обеспечения конфиденциальности трафика;

• обеспечения невозможности отказа от факта отправки сообщения абонентом - передатчиком и приема сообщения абонентом - приемником.

Состояние международной нормативно-методической базы С целью систематизации анализа текущего состояния международной нормативно-методической базы в области безопасности ИТ необходимо использовать некоторую классификацию направлений стандартизации. В общем случае, можно выделить следующие направления.

1. Общие принципы управления информационной безопасностью.

2. Модели безопасности ИТ.

3. Методы и механизмы безопасности ИТ (такие, как, например:

методы аутентификации, управления ключами и т.п.).

4. Криптографические алгоритмы.

5. Методы оценки безопасности информационных систем.

6. Безопасность EDI-технологий.

7. Безопасность межсетевых взаимодействий (межсетевые экраны).

8. Сертификация и аттестация объектов стандартизации.

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

На роль такого документа претендует, находящийся в стадии утверждения проект международного стандарта ISO/IEC DTR 13335-1,2, – «Информационная технология. Руководство по управлению безопасностью информационных технологий». Данный документ содержит:

• определения важнейших понятий, непосредственно связанных с проблемой управления безопасностью ИТ;

• определения важных архитектурных решений по созданию систем управления безопасностью ИТ (СУБ ИТ), в том числе, определение состава элементов, задач, механизмов и методов СУБ ИТ;

• описание типового жизненного цикла и принципов функционирования СУБ ИТ;

• описание принципов формирования политики (методики) управления безопасностью ИТ;

• методику анализа исходных данных для построения СУБ ИТ, в частности методику идентификации и анализа состава объектов защиты, уязвимых мест информационной системы, угроз безопасности и рисков и др.;

• методику выбора соответствующих мер защиты и оценки остаточного риска;

• принципы построения организационного обеспечения управления в СУБ ИТ и пр.

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

Построение моделей позволяет структурировать и конкретизировать исследуемые объекты, устранить неоднозначности в их понимании, разбить решаемую задачу на подзадачи, и, в конечном итоге, выработать необходимые решения.

Можно выделить следующие международные стандарты и другие документы, в которых определяются основные модели безопасности ИТ:

• ISO/IEC 7498-2-89 - «Информационные технологии. Взаимосвязь открытых системы. Базовая эталонная модель. Часть 2. Архитектура информационной безопасности» (кратко описанная выше);

• ISO/IEC DTR 10181-1 – «Информационные технологии.

Взаимосвязь открытых систем. Основы защиты информации для открытых систем. Часть 1. Общее описание основ защиты информации ВОС»;

• ISO/IEC DTR 10745 – «Информационные технологии. Взаимосвязь открытых систем. Модель защиты информации верхних уровней»;

• ISO/IEC DTR 11586-1 – «Информационные технологии.

Взаимосвязь открытых систем. Общие функции защиты верхних уровней. Часть 1. Общее описание, модели и нотация»;

• ISO/IEC DTR 13335-1 – «Информационные технологии.

Руководство по управлению безопасностью информационных технологий. Часть 1. Концепции и модели безопасности информационных технологий».

Стандартизация методов и механизмов безопасности ИТ На определенном этапе задача защиты информационных технологий разбивается на частные подзадачи, такие как обеспечение конфиденциальности, целостности и доступности. Для этих подзадач должны вырабатываться конкретные решения по организации взаимодействия объектов и субъектов информационных систем. К таким решениям относятся методы:

• аутентификации субъектов и объектов информационного взаимодействия, предназначенные для предоставления взаимодействующим сторонам возможности удостовериться, что противоположная сторона действительно является тем, за кого себя выдает;

• шифрования информации, предназначенные для защиты информации в случае перехвата ее третьими лицами;

• контроля целостности, предназначенные для обеспечения того, чтобы информация не была искажена или подменена;

• управления доступом, предназначенные для разграничения доступа к информации различных пользователей;

• повышения надежности и отказоустойчивости функционирования системы, предназначенные для обеспечения гарантий выполнения информационной системой целевых функций;

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

Организации по стандартизации уделяют большое внимание разработке типовых решений для указанных выше аспектов безопасности.

К ним, в первую очередь отнесем следующие международные стандарты:

• ISO/IEC 9798-91 – «Информационные технологии. Защита информации. Аутентификация объекта».

Часть 1. Модель.

Часть 2. Механизмы, использующие симметричные криптографические алгоритмы.

Часть 3. Аутентификация на базе алгоритмов с открытыми ключами.

Часть 4. Механизмы, использующие криптографическую контрольную функцию.

Часть 5. Механизмы, использующие алгоритмы с нулевым разглашением.

• ISO/IEC 09594-8-88 – «Взаимосвязь открытых систем. Справочник.

Часть 8. Основы аутентификации»;

• ISO/IEC 11577-94 – «Информационные технологии. Передача данных и обмен информацией между системами. Взаимосвязь открытых систем. Протокол защиты информации на сетевом уровне»;

• ISO/IEC DTR 10736 – «Информационные технологии. Передача данных и обмен информацией между системами. Протокол защиты информации на транспортном уровне»;

• ISO/IEC CD 13888 – «Механизмы предотвращения отрицания».

Часть 1. Общая модель.

Часть 2. Использование симметричных методов.

Часть 3. Использование асимметричных методов;

• ISO/IEC 8732-88 – «Банковское дело. Управление ключами»;

• ISO/IEC 11568-94 – «Банковское дело. Управление ключами».

Часть 1. Введение. Управление ключами.

Часть 2. Методы управления ключами для симметричных шифров.

Часть 3. Жизненный цикл ключа для симметричных шифров;

• ISO/IEC 11166-94 – «Банковское дело. Управление ключами посредством асимметричного алгоритма».

Часть 1. Принципы процедуры и форматы.

Часть 2. Принятые алгоритмы, использующие криптосистему RSA;

• ISO/IEC DIS 13492 – «Банковское дело. Управление ключами, относящимися к элементам данных»;

• ISO/IEC CD 11770 – «Информационные технологии. Защита информации. Управление ключами».

Часть 1. Общие положения.

Часть 2. Механизмы, использующие симметричные методы.

Часть 3. Механизмы, использующие асимметричные методы;

• ISO/IEC DTR 10181- «Информационные технологии. Взаимосвязь открытых систем. Основы защиты информации для открытых систем».

Часть 1. Общее описание основ защиты информации в ВОС.

Часть 2. Основы аутентификации.

Часть 3. Управление доступом.

Часть 4. Безотказность получения.

Часть 5. Конфиденциальность.

Часть 6. Целостность.

Часть 7. Основы проверки защиты.

К этому же уровню следует отнести стандарты, описывающие интерфейсы механизмов безопасности ИТ:

• ISO/IEC 10164-7-92. «Информационные технологии. Взаимосвязь открытых систем. Административное управление системы. Часть 7.

Функции уведомления о нарушениях информационной безопасности».

• ISO/IEC DTR 11586. «Информационные технологии. Взаимосвязь открытых систем. Общие функции защиты верхних уровней».

Часть 1. Общее описание, модели и нотация.

Часть 2. Определение услуг сервисного элемента обмена информацией защиты.

Часть 3. Спецификация протокола сервисного элемента обмена информацией защиты.

Часть 4. Спецификация синтаксиса защищенной передачи.

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

Поэтому в ряде случаев при использовании некоторых стандартов может потребоваться их адаптация к отечественным криптоалгоритмам.

Стандартизация международных криптографических алгоритмов Организация ISO стандартизировала ряд криптографических алгоритмов в таких международных стандартах, как, например:

• ISO/IEC 10126-2-91 – «Банковское дело. Процедуры шифрования сообщения. Часть 2. Алгоритм DEA»;

• ISO/IEC 8732-87 – «Информационные технологии. Защита информации. Режимы использования 64-битного блочного алгоритма»;

• ISO/IEC 10116-91- «Банковское дело. Режимы работы n-битного блочного алгоритма шифрования»;

• ISO/IEC 10118-1,2-88 – «Информационные технологии.

Шифрование данных. Хэш-функция для цифровой подписи»;

• ISO/IEC CD 10118-3,4 – «Информационные технологии. Защита информации. Функции хэширования»;

• ISO/IEC 9796-91 – «Информационные технологии. Схема электронной подписи, при которой производится восстановление сообщения»;

• ISO/IEC CD 14888 – «Информационные технологии. Защита информации. Цифровая подпись с добавлением».

Однако широкое внедрение этих алгоритмов представляется малореальным, поскольку техническая политика крупных индустриальных государств, в т.ч. и Российской Федерации, направлена, как правило, на использование собственных криптоалгоритмов.

15.1.2. Отечественная нормативно-правовая база, под действие которой подпадают АС различного назначения Стандартизация в области защиты информации от НСД К основным стандартам и нормативным техническим документам по безопасности информации, в первую очередь, относится комплект руководящих документов Гостехкомиссии России (1998 г), которые в соответствии с Законом «О стандартизации» можно отнести к отраслевым стандартам, в том числе «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности средств вычислительной техники»», «Автоматизированные системы.

Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», «Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от несанкционированного доступа в автоматизированных системах и средствах вычислительной техники», «Средства вычислительной техники.

Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации», ГОСТ Р 50739-95 «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования».

Особенности защиты программ нашли свое отражение в следующих руководящих документах: РД «Защита информации от несанкционированного доступа к информации. Программное обеспечение средств защиты информации. Классификация по уровню контролю отсутствия недекларированных возможностей» и проект РД «Антивирусные средства. Показатели защищенности и требования по защите от вирусов».

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

Во втором документе устанавливается классификация средств антивирусной защиты по уровню обеспечения защиты от воздействия программ-вирусов на базе перечня показателей защищенности и совокупности описывающих их требований.

Кроме того, следующие нормативные документы, так или иначе косвенно регламентируют отдельные вопросы обеспечения безопасности ПО:

• ГОСТ 28195-89. Оценка качества программных средств. Общие положения;

• ГОСТ 21552-84. Средства вычислительной техники. ОТТ, приемка методы испытаний, маркировка, упаковка, транспортировка и хранение;

• ГОСТ ВД 21552-84. Средства вычислительной техники. ОТТ, приемка методы испытаний, маркировка, упаковка, транспортировка и хранение;

• ТУ на конкретный вид продукции (ПО).

Стандартизация отечественных криптографических алгоритмов Отечественные стандарты [ГОСТ1-ГОСТ4] описывают криптографические алгоритмы, достаточные для решения большинства прикладных задач:

• ГОСТ 28147-89 «Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования» описывает три алгоритма шифрования данных (из них один - так называемый «режим простой замены» - является служебным, два других – «режим гаммирования» и «режим гаммирования с обратной связью» - предназначены для шифрования целевых данных) и алгоритм выработки криптографической контрольной суммы (имитовставки), предназначенной для контроля целостности информации;

• ГОСТ Р 34.10-94 «Информационная технология.

Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма»;

• ГОСТ Р 34.11-94 «Информационная технология.

Криптографическая защита информации. Функция хэширования»$ • ГОСТ Р 34.10-2002 «Информационная технология.

Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма».

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

15.2. СЕРТИФИКАЦИОННЫЕ ИСПЫТАНИЯ ПРОГРАММНЫХ СРЕДСТВ До получения готового программного изделия оценить его показатели качества можно лишь вероятностным образом на макроуровне рассмотрения структуры программного комплекса. Поэтому возникает насущная потребность в организации специального этапа в процессе создания ПО необходимого для подтверждения соответствия показателям качества реального программного изделия заданным к нему требованиям. Причем контроль выполнения этих требований должен осуществляться с учетом предполагаемых условий применения при форсированных нагрузках и тестировании всех установленных режимов. В рамках создания современных информационных технологий решение задач испытания ПО и получения документального подтверждения требуемых показателей качества программ объединяется в рамках процесса сертификации.

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

Сертификация программного обеспечения КС возможна при выполнении следующих условий:

• разработке шкалы показателей качества с учетом специфики целевого использования программных средств и набора их функциональных характеристик;

• каталогизации программ, как объекта сертификации на основе опыта их эксплуатации;

• создании специализированного центра сертификации, выполняющего роль «третейской» организации контроля качества;

• разработке нормативно-технической базы, регламентирующей сертификацию программного обеспечения;

• разработке эталонов программных средств, которые удовлетворяют требованиям технических заданий на разработку разнотипных программных комплексов;

• разработке специальной технологии испытаний, определяющей объем и содержание сертификационных испытаний;

• реализации комплекса тестового программного обеспечения для широкого спектра программных изделий.

В процессе сертификации сложного ПО следует выделить два аспекта:

методический и технологический. Методический аспект связан с разработкой комплекса методик сертификации программного обеспечения с учетом специфики его применения, а технологический с автоматизацией процесса применения методического аппарата.

Следует отметить, что по некоторым оценкам до 70% общих затрат на создание и внедрение сложных программных комплексов приходится на реализацию процесса их сертификации. Причем значительная доля этих затрат относится к организации аппаратно-программной платформы, моделирующих средств и тестового обеспечения стенда сертификации.

Кроме того, важнейшим вопросом создания качественных программных изделий является обеспечение технологической безопасности ПО на этапе сертификационных стендовых испытаний.

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

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

Сертификационные испытания программных средств, в том числе защищенных программных средств и программных средств контроля защищенности проводятся в государственных и отраслевых сертификационных центрах (испытательных лабораториях).

Право на проведение сертификационных испытаний защищенных средств вычислительной техники, в том числе программных средств предоставляется Гостехкомиссией России по согласованию с Госстандартом России предприятиям-разработчикам защищенных СВТ, специализированным организациям ведомств, разрабатывающих защищенные СВТ, в том числе программные средства.

В соответствии с «Положением о сертификации продукции по требованиям безопасности информации» и «Положением о сертификации средств защиты информации» (см., например, [Зак]) по результатам сертификационных испытаний оформляется акт, а разработчику выдается сертификат, заверенный в Гостехкомиссии России и дающий право на использование и распространение этих средств как защищенных.

Средства, получившие сертификат, включаются в номенклатуру защищенных СВТ, в том числе программных средств.

Разработанные программные средства после их приемки представляются для регистрации в специализированный фонд Государственного фонда алгоритмов и программ.

Практические аспекты проведения сертификационных испытаний ПО приведены в приложении.

15.3. БЕЗОПАСНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ЧЕЛОВЕЧЕСКИЙ ФАКТОР. ПСИХОЛОГИЯ ПРОГРАММИРОВАНИЯ.

15.3.1. Человеческий фактор Преднамеренные и непреднамеренные нарушения безопасности программного обеспечения компьютерных систем большинство отечественных и зарубежных специалистов связывают с деятельностью человека. При этом технические сбои аппаратных средств КС, ошибки программного обеспечения и т.п. часто рассматриваются лишь как второстепенные факторы, связанные с проявлением угроз безопасности.

С некоторой степенью условности злоумышленников в данном случае можно разделить на два основных класса:

• злоумышленники-любители (будем называть их хакерами);

• злоумышленники-профессионалы.

Хакеры - это люди, увлеченные компьютерной и телекоммуникационной техникой, имеющие хорошие навыки в программировании и довольно любознательные. Их деятельность в большинстве случаев не приносит особого вреда компьютерным системам.

Ко второму классу можно отнести отечественные, зарубежные и международные криминальные сообщества и группы, а также правительственные организации и службы, которые осуществляют свою деятельность в рамках концепции «информационной войны». К этому же классу можно отнести и сотрудников самих предприятий и фирм, ведущих разработку и эксплуатацию программного обеспечения.

Хакеры и группы хакеров Хакеры часто образуют небольшие группы. Иногда эти группы периодически собираются, а в больших городах хакеры и группы хакеров встречаются регулярно. Но основная форма взаимодействия осуществляется через Интернет, а ранее - через электронные доски BBS.

Как правило, каждая группа хакеров имеет свой определенный (часто критический) взгляд на другие группы. Хакеры часто прячут свои изобретения от хакеров других групп и даже от соперников в своей группе.

Существуют несколько типов хакеров. Это хакеры, которые:

• стремятся проникнуть во множество различных компьютерных систем (маловероятно, что такой хакер объявится снова после успешного проникновения в систему);

• получают удовольствие, оставляя явный след того, что он проник в систему;

• желают воспользоваться оборудованием, к которому ему запрещен доступ;

• охотятся за конфиденциальной информацией;

• собираются модифицировать определенный элемент данных, например баланс банка, криминальную запись или экзаменационные оценки;

• пытаются нанести ущерб «вскрытой» (обезоруженной) системе.

Группы хакеров, с некоторой степенью условности, можно разделить на следующие:

• группы хакеров, которые «получают удовольствие» от вторжения и исследования больших ЭВМ, которые используются в различных государственных учреждениях;

• группы хакеров, которые специализируются на телефонной системе;

• группы хакеров - коллекционеров кодов, - это хакеры, запускающие перехватчики кода, которые ищут карты вызовов (calling card) и номера PBX (private branch exchange - частная телефонная станция с выходом в общую сеть);

• группы хакеров, которые специализируются на операциях в финансово-кредитной сфере (Они используют компьютеры для кражи денег, вычисления номеров кредитных карточек и другой ценной информации, а затем продают свои услуги и методы другим, включая членов организованных преступных группировок. Эти хакеры могут скупать у коллекционеров кодов номера PBX и продавать их за 200-500$, и подобно другим видам информации неоднократно. Архивы кредитных бюро, информационные срезы баз данных уголовных архивов правоохранительных органов и баз данных других государственных учреждений также представляют для них большой интерес. Хакеры в этих группах, как правило, не находят взаимопонимания с другими хакерами);

• группы хакеров, которые специализируются на сборе и торговле пиратским программным обеспечением.

Типовой потрет хакера Ниже приводится два обобщенных портрета хакера, один составлен по данным работы [СМ] и характеризует скорее зарубежных хакеров любителей, в то время как второй - это обобщенный портрет отечественного злонамеренного хакера, составленный Экспертно криминалистическим центром МВД России [Сы].

В первом случае отмечается, что многие хакеры обладают следующими особенностями [СМ]:

• мужчина: большинство хакеров - мужчины, как и большинство программистов;

• молодой: большинству хакеров от 14 до 21 года, и они учатся в институте или колледже. Когда хакеры выходят в деловой мир в качестве программистов, их программные проекты источают большую часть их излишней энергии, и корпоративная обстановка начинает менять их жизненную позицию. Возраст компьютерных преступников показан на рис. 15.1 [СМ];

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

• концентрирован на понимании, предсказании и управлении: эти три условия составляет основу компетенции, мастерства и самооценки и стремительные технологические сдвиги и рост разнообразного аппаратного и программного обеспечения всегда будут вызовом для хакеров;

• увлечен компьютерами: для многих пользователей компьютер - это необходимый рабочий инструмент. Для хакера же - это «удивительная игрушка» и объект интенсивного исследования и понимания;

• отсутствие преступных намерений: по данным [СМ] лишь в 10% рассмотренных случаев компьютерной преступности нарушения, совершаемые хакерами, привели к разрушению данных компьютерных систем. В связи с этим можно предположить, что менее 1% всех хакеров являются злоумышленниками.

25% 20% 15% Процентное соотношение 10% возрастов 5% 0% <20 30 40 Рис. 15.1. Возрастное распределение обнаруженных компьютерных преступников Обобщенный портрет отечественного хакера выглядит следующим образом [Сы]: это мужчина в возрасте от 15 до 45 лет, либо имеющий многолетний опыт работы на компьютере, либо почти не обладающий таким опытом;

в прошлом к уголовной ответственности не привлекался;

является яркой, мыслящей личностью, способной принимать ответственные решения;

хороший, добросовестный работник;

по характеру нетерпимый к насмешкам и к потере своего социального статуса в рамках окружающей его группы людей;

любит уединенную работу;

приходит на службу первым и уходит последним;

часто задерживается на работе после окончании рабочего дня и очень редко использует отпуска и отгулы.

Криминальные сообщества и группы, сценарий взлома компьютерной системы В связи со стремительным ростом информационных технологий и разнообразных компьютерных и телекоммуникационных средств и систем, наблюдается экспоненциальный рост как количества компьютерных атак, так и объем нанесенного от них ущерба. Анализ показывает, что такая тенденция постоянно сохраняется [Ка1].

За последнее время в нашей стране не отмечено ни одного компьютерного преступления, которое было бы совершено одиночкой [Сы]. Более того, известны случаи, когда организованными преступными группировками нанимались бригады из десятков хакеров. Им предоставлялись отдельные охраняемые помещения, оборудованные самыми передовыми компьютерными средствами и системами для проникновения в компьютерные сети коммерческих банков.

Специалисты правоохранительных органов России неоднократно отмечали тот факт, что большинство компьютерных преступлений в банковской сфере совершается при непосредственном участии самих служащих коммерческих банков. Результаты исследований, проведенных с привлечением банковского персонала, показывают, что доля таких преступлений приближается к отметке 70%. При осуществлении попытки хищения 2 млрд. рублей из филиала одного крупного коммерческого банка преступники оформили проводку фиктивного платежа с помощью удаленного доступа к компьютеру через модем, введя пароль и идентификационные данные, которые им передали сообщники из состава персонала этого филиала. Далее эти деньги были переведены в соседний банк, где преступники попытались снять их со счета, оформив поддельное платежное поручение [Сы].

По данным Экспертно-криминалистического центра МВД России принципиальный сценарий взлома защитных механизмов банковской компьютерной системы представляется следующим. Компьютерные злоумышленники-профессионалы обычно работают только после тщательной предварительной подготовки. Они снимают квартиру на подставное лицо в доме, в котором не проживают сотрудники ФСБ, МВД или МГТС. Подкупают сотрудников банка, знакомых с деталями электронных платежей и паролями, и работников телефонной станции, чтобы обезопасить себя на случай поступления запроса от службы безопасности банка. Нанимают охрану из бывших сотрудников МВД.

Чаще всего взлом банковской компьютерной системы осуществляется рано утром, когда дежурный службы безопасности теряет свою бдительность, а вызов помощи затруднен.

Злоумышленники в профессиональных коллективах программистов-разработчиков Согласно существующей статистики в коллективах людей занятых той или иной деятельностью, как правило, только около 85% являются вполне лояльными (честными), а остальные 15% делятся примерно так: 5% - могут совершить что-нибудь противоправное, если, по их представлениям, вероятность заслуженного наказания мала;

5% - готовы рискнуть на противоправные действия, даже если шансы быть уличенным и наказанным складываются 50 на 50;

5% - готовы пойти на противозаконный поступок, даже если они почти уверены в том, что будут уличены и наказаны. Такая статистика в той или иной мере может быть применима к коллективам, участвующим в разработке и эксплуатации информационно-технических составляющих компьютерных систем.

Таким образом, можно предположить, что не менее 5% персонала, участвующего в разработке и эксплуатации программных комплексов, способны осуществить действия криминального характера из корыстных побуждений либо под влиянием каких-нибудь иных обстоятельств.

По другим данным [СМ] считается, что от 80 до 90% компьютерных нарушений являются внутренними, в частности считается, что на каждого «... подлого хакера приходится один обозленный и восемь небрежных работников, и все они могут производить разрушения изнутри».

15.3.2. Информационная война В настоящее время за рубежом в рамках создания новейших оборонных технологий и видов оружия активно проводятся работы по созданию так называемых средств нелетального воздействия [Ка1]. Эти средства позволяют без нанесения разрушающих ударов (например, современным оружием массового поражения) по живой силе и технике вероятного противника выводить из строя и/или блокировать его вооружение и военную технику, а также нарушать заданные стратегии управления войсками.

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

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

Появление информационного оружия приводит к изменению сущности и характера современных войн и появлению нового вида вооруженного конфликта - информационная война.

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

Ввиду того, что в мировой практике нет прецедента ведения широкомасштабной информационной войны, а имеются лишь некоторые прогнозы и зафиксированы отдельные случаи применения информационного оружия в ходе вооруженных конфликтов и в процессе деятельности крупных государственных и коммерческих организаций [Ка1], анализ содержания информационной войны за рубежом возможен по отдельным публикациям, так как, по некоторым данным информация по этой проблеме за рубежом строго засекречена.

Анализ современных методов ведения информационной борьбы позволяет сделать вывод о том, что к прогнозируемым формам информационной войны можно отнести следующие:

• глобальная информационная война;

• информационные операции;

• преднамеренное изменение замысла стратегической и тактической операции;

• дезорганизация жизненно важных для страны систем;

• нарушение телекоммуникационных систем;

• обнуление счетов в международной банковской системе;

• уничтожение (искажение) баз данных и знаний важнейших государственных и военных объектов.

К методам и средствам информационной борьбы в настоящее время относят:

• воздействие боевых компьютерных вирусов и преднамеренных дефектов диверсионного типа;

• несанкционированный доступ к информации;

• проявление непреднамеренных ошибок ПО и операторов компьютерных систем (в т.ч. за счет использования средств информационно-психологического воздействия на личный состав);

• воздействие радиоэлектронными излучениями;

• физические разрушения систем обработки информации.

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

15.3.3. Психология программирования При создании высокоэффективных, надежных и безопасных программ (программных комплексов), отвечающих самым современным требованиям к их разработке, эксплуатации и модернизации необходимо не только умело пользоваться предоставляемой вычислительной и программной базой современных компьютеров, но и учитывать интуицию и опыт разработчиков языков программирования и прикладных систем.

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

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

К целям психологии программирования наряду с улучшением использования компьютера, основанного на глубоком знании свойств мышления человека, относится и определение, как правило, экспериментальным путем, склонностей и способностей программиста как личности. Особенности личности играют критическую роль в определении (исследовании) рабочего стиля отдельного программиста, а также особенностей его поведения в коллективе разработчиков программного обеспечения. Ниже приводится список характеристик личности и их предполагаемых связей с программированием. При этом особое внимание уделяется тем личным качествам программиста, которые могут, в той или иной степени, оказать влияние на надежность и безопасность разрабатываемого им программного обеспечения.

Внутренняя/внешняя управляемость. Личности с выраженной внутренней управляемостью стараются подчинять себе обстоятельства и убеждены в способности сделать это, а также в способности повлиять на свое окружение и управлять событиями. Личности с внешней управляемостью (наиболее уязвимы с точки зрения обеспечения безопасности программного обеспечения) чувствуют себя жертвами не зависящих от них обстоятельств и легко позволяют другим доминировать над ними.

Высокая/низкая мотивация. Личности с высокой степенью мотивации способны разрабатывать очень сложные и сравнительно надежные программы. Руководители, способные повысить уровень мотивации, в то же время, могут стимулировать своих сотрудников к созданию программ с высоким уровнем их безопасности.

Умение быть точным. На завершающих этапах составления программ необходимо особое внимание уделять подробностям и готовности проверить и учесть каждую деталь. Это позволит повысить вероятность обнаружения программных дефектов как привнесенных в программу самим программистом (когда нарушитель может ими воспользоваться в своих целях), так и другими программистами (в случае, если некоторые из них могут быть нарушителями) при создании сложных программных комплексов коллективом разработчиков.

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

Корпоративная этика Особый психологический настрой и моральные стимулы программисту может создать особые корпоративные условия его деятельности, в частности различные моральные обязательства, оформленные в виде кодексов чести. Ниже приводится «Кодекс чести пользователя компьютера» [СМ].

• Обещаю не использовать компьютер в ущерб другим людям.

• Обещаю не вмешиваться в работу компьютера других людей.

• Обещаю «не совать нос» в компьютерные файлы других людей.

• Обещаю не использовать компьютер для воровства.

• Обещаю не использовать компьютер для лжесвидетельства.

• Обещаю не копировать и не использовать чужие программы, которые были оплачены не мною.

• Обещаю не использовать компьютерные ресурсы других людей без разрешения и соответствующей компенсации.

• Обещаю не присваивать результаты интеллектуального труда других людей.

• Обещаю думать об общественных последствиях разрабатываемых мною программ или систем.

• Обещаю всегда использовать компьютер с наибольшей пользой для живущих ныне и будущих поколений.

ЗАКЛЮЧЕНИЕ Количество и уровень деструктивности угроз безопасности для программных комплексов компьютерных систем как со стороны внешних, так и со стороны внутренних источников угроз постоянно возрастает. Это объясняется стремительным развитием компьютерных и телекоммуникационных средств, глобальных информационных систем, необходимостью разработки для них сложного программного обеспечения с применением современных средств автоматизации процесса проектирования программ. Кроме того, это объясняется значительным или даже резким повышением в последнее время активности деятельности хакеров и групп хакеров, атакующих компьютерные системы, криминальных групп компьютерных взломщиков, различных специальных подразделений и служб, осуществляющих свою деятельность в области создания средств воздействия на критически уязвимые объекты информатизации.

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

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

Необходимой составляющей проблемы обеспечения информационной безопасности программного обеспечения является общегосударственная система стандартов и других нормативных и методических документов по безопасности информации, а также международные стандарты и рекомендации по управлению качеством программного обеспечения (ознакомиться с большей их частью можно в главе 15 и приложении), которые позволяет предъявить к создаваемым и эксплуатируемым программных комплексам требуемый уровень реализации защитных функций.

Изложенный материал, по мнению автора, позволит при изучении технологии проектирования защищенного программного обеспечения избежать многих ошибок, которые могут существенно повлиять на качество проекта и эффективность конечной системы в целом при ее реализации на объектах информатизации различного назначения.

Pages:     | 1 |   ...   | 4 | 5 ||



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.