Метод привязки к идентификатору

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

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

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

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

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

Метод создания самотестирующейся расчетной программы с эффективным тестирующим модулем

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

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

Пусть для функции Y = f (X) существует пара функций (gc, hc)Y таких, что:

Y = gc (f (a1), ..., f (ac)),

X = hc (a1, ..., ac).

Легко увидеть, что если значения ai

выбраны из In в соответствии с распределением Dp, тогда пара функций (gc, hc)Y обеспечивает выполнение для функции Y = f (X) свойства случайной самосводимости. Пару функций (gc, hc)Y будем называть ST-парой функций для функции Y = f (X).

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

Предлагаемый метод верификации расчетной программы P

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

 



Алгоритм ST

1. Определить множество  такое, что , где   выбраны случайно из входного подмножества In.

2. Вызвать программу P для вычисления значения

3. Вызвать c раз программу P для вычисления множества значений

4. Определить значения

5. Если , то принимается решение, что программа P корректна на множестве значений входных параметров  в противном случае данная программа является некорректной.

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

где    ti

и tx -         время выполнения программы P при входных значениях ai и X* соответственно;

tg и  -       время определения значения функции gc

и множества A* соответственно:

TP (X) -        временная (не асимптотическая) сложность выполнения программы P;

Kgh (X, c) -     коэффициент временной сложности программной реализации функции gc и определения A* по отношению к временной сложности программы P (по предположению он составляет константный мультипликативный фактор от TP (X), а его значение меньше 1). Для традиционного вышеуказанного метода тестирования время выполнения и сравнения полученного результата с эталонным значением составляет:

,

где    tie

и txe -       время определения эталонных значений функции Y = f (X) при значениях ai и X* соответственно (в общем случае, не может быть меньше времени выполнения программы).

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



Так как, коэффициент Kgh < 1, а c ³ 2, то получаем относительный выигрыш по оперативности испытания расчетных программ указанного типа (обладающих свойством случайной самосводимости) более чем в 1.5 раза.

Методологические вопросы проведения испытаний ПО

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

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

I. Создание методов и средств оценки качества оцениваемого ПО.

II. Разработка заключения о качестве ПО.

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

Методы, основанные на работе с переходами и стеком

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

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

Методы противодействия динамическим способам снятия защиты программ от копирования

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

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

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

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

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

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

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

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

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

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

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

Методы внедрения РПС

Можно выделить следующие основные методы внедрения РПС[ПАС].

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

Маскировка закладки под «безобидный» модуль расширения программной среды. Многие программные среды допускают свое расширение дополнительными программными модулями. Например, для операционных систем семейства Microsoft Windows модулями расширения могут выступать динамически подгружаемые библиотеки (DLL) и драйверы устройств. В таких модулях расширения может содержаться РПС, которое может потенциально внедрено в систему. Данный метод фактически является частным случаем предыдущего метода и отличается от него только тем, что закладка представляет собой не прикладную программу, а модуль расширения программной среды.

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

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

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

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

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

Методы защиты программ от исследования

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

В первом случае защита может быть основана на шифровании конфиденциальной части программы, а во втором - на блокировании доступа к исполняемому коду программы в оперативной памяти со стороны отладчиков [ЗШ]. Кроме того, перед завершением работы защищаемой программы должен обнуляться весь ее код в оперативной памяти. Это предотвратит возможность несанкционированного копирования из оперативной памяти дешифрованного исполняемого кода после выполнения защищаемой программы.

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

·     инициализатор;

·     зашифрованную конфиденциальную часть;

·     деструктор (деициниализатор).

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

·     сохранение параметров операционной среды функционирования (векторов прерываний, содержимого регистров процессора и т.д.);

·     запрет всех внутренних и внешних прерываний, обработка которых не может быть запротоколирована в защищаемой программе;

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

·     передача управления конфиденциальной части программы.

Конфиденциальная часть программы

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

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

·     обнуление конфиденциального кода программы в оперативной памяти;

·     восстановление параметров операционной системы (векторов прерываний, содержимого регистров процессора и т.д.), которые были установлены до запрета неконтролируемых прерываний;

·     выполнение операций, которые невозможно было выполнить при запрете неконтролируемых прерываний;

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

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

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

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

·     проверку количества занимаемой защищаемой программой оперативной памяти;

·     сравнение с объемом, к которому программа адаптирована, и принятие необходимых мер в случае несоответствия;

·     контроль времени выполнения отдельных частей программы;

·     блокировку клавиатуры на время отработки особо критичных алгоритмов.

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

Методы защиты программ от несанкционированных изменений

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

·

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

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

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

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

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

- с внесенной программным закладкой и f

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

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

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

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

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

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

Многосторонний протокол схемного вычисления

Ниже описывается m-арный аналог вышеописанного субпротокола «Редукция КВm=2». Показывается, что вычисления любой детерминированной функции, вычислимой посредством арифметической схемы над GF(2), конфиденциально сводимы к вычислениям функции из уравнений (3.3) - (3.4).

В частности разделение битового значения v

между m

процессорами означает равномерно выбранную m-арную последовательность битов (v1,...,vm) так, что v=

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

В начале мы рассмотрим нумерацию всех линий схемы. Входные линии схемы (n) для каждого процессора будут пронумерованы 1,2,...,mn так, что для j=1,...,n j-тый вход процессора i соответствует ((i-1)n+j)-той линии. Линии будут пронумерованы так, чтобы выходные линии каждого вентиля имеют большую нумерацию, чем его входные линии. Для простоты предположим, что каждый процессор получает n выходных битов, и что j-тый выходной бит j-того процессора соответствуют линии

N-(m+1-i)+j, где N

– размер схемы.

Ниже приводится алгоритм сведения любой детерминированной

m-арной вычислимой функции (m³2) к функции, вычислимой в соответствии с уравнениями (3.3) и (3.4).

Редукция к КВm

Вход.

Процессор i

содержит строку битов xi1...ximÎ{0,1}m, i=1,...,m.

1. Разделение входов. Каждый процессор делит каждый из своих входных битов с другим процессором. То есть для каждого i=1,...,m и j=1,...,n и каждого k¹i процессор i равномерно выбирает бит rk(i-1)n+j и посылает его процессору k, как долю входной линии (с нумерацией (i-1)n+j) последнего. Процессор i устанавливает свою собственную долю на входной линии с нумерацией (i-1)n+j

в значение xij+

.

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

Предположим, что процессоры имеют общие две входные линии вентиля, то есть для i=1,...,m процессор i содержит доли ai,bi, где a1,...,am - доли на первой линии и b1,...,bm - доли на второй линии. Рассмотрим два случая.

2.1. Эмуляция аддитивного вентиля. Каждый процессор только устанавливают свою долю выходной линии вентиля в значение ai+bi.

2.2. Эмуляция мультипликативного вентиля. Доли выходной линии вентиля получаются посредством вызова оракула для вычисления функции (см.(3.4)-(3.5), где процессор i

обеспечивает вход (часть запроса) (ai,bi). После ответов оракула, каждый из процессоров устанавливают свою долю выходной линии вентиля в значение равное своей части ответа оракула.

3. Восстановление выходных битов. Как только доли выходных линий схемы вычислены, каждый процессор посылает долю с каждой из таких линий процессору, с которым линия связана. То есть для i=1,...,m и j=1,...,n

каждый процессор    посылает свою долю с линии N-(m+1-i)n+j процессору i. Каждый из процессоров восстанавливает соответствующие выходные биты, складывая соответствующие m долей; то есть доли, которую он получил на шаге 2 и m-1 долей, полученных на текущем шаге.

Выход.

Каждый процессор локально выдает биты, восстановленные на шаге 3.

Сначала необходимо проверить, что выходы действительно корректны. Это можно сделать методом индукции, которая состоит в том, что значение доли каждой линии прибавляются к корректному значению на линии. Базис индукции – номер входной линии схемы. А именно,

((i-1)n+j)-тая линия имеет значение xij

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

и что их доли a1,...,am и b1,...,bm действительно удовлетворяют =a

и =b. В случае аддитивного вентиля доли на выходной линии установить в значения a1+b1,...,am+bm, что удовлетворяет =()+()=a+b.


В случае мультипликативного вентиля доли выходной линии были установлены в значение c1,...,cm так, что =()+(). Таким образом, =a·b, что и требовалось показать.

В работе [Go2] приводятся формальные аргументы для конфиденциального сведения вычисления на арифметической схеме над GF(2) к

m-арной функции, вычислимой в соответствии с уравнениями (3.3)-(3.4). А следующая теорема, устанавливает главный результат для конфиденциального вычисления любой вычислимой функции для многостороннего протокола взаимодействия.

Теорема 3.5.

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

Модель Джелинского-Моранды

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

Модификация модели Джелинского-Моранды была предложена Шиком и Волвертоном. В основе модели Шика-Волвертона лежит предположение, согласно которому частота ошибок пропорциональна не только количеству ошибок в программах, но также и времени отладки, т.е. вероятность обнаружения ошибок с течением времени возрастает.

Модель Шумана

Целесообразность применения модели Шумана[ТЛН] для оценки надежности программного обеспечения зависят от принятых допущений и условий, наиболее существенным из которых является условие существования программы-исследователя системы. Остальные допущения и условия носят статический характер и не связаны с какими-либо специфическими свойствами программного обеспечения. По существу они сводятся к следующему:

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

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

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

Модель взаимодействия

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

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

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

Модели доступа

Необходимо начать с определения модели доступа как последовательности ячеек памяти, к которым ЦП обращается в процессе вычислений. Это определение распространяется также на оракульный ЦП.

Определение5.7. Модель доступа, обозначаемая как Аk(y), детерминированной RAMk-машины

на входе y – это последовательность (a1,...,ai,...) такая, что для каждого i, i-тое сообщение, посланное машиной CPUk

при ее взаимодействии с машиной MEMk(y), имеет форму (·,ai,·).

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

Определение 5.8. Модель доступа, обозначаемая как

, вероятностной RAMk-машины на входе y

– это случайная величина, которая принимает значение модели доступа машины RAMk на некотором входе y и при доступе к однородно выбранной функции f.

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

Определение 5.9. Для каждого kÎN определим забывающую RAMk-машину

как вероятностную RAMk-машину, удовлетворяющую следующему условию. Для каждых двух строк y1 и y2, если ½

½ и½½ идентично распределены, тогда также идентично распределены  и .

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

Определения RAM-машины и забывающей RAM-машины необходимо для того, чтобы дать точное определение забывающего моделирования

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

Определение 5.10. Для данных машин, - вероятностной RAM'k', и RAMk вероятностная машина RAM'k' моделирует забывающим образом RAMk, если выполняются следующие условия:

вероятностная машина RAM'k'

моделирует RAMk с вероятностью 1. Другими словами, для каждого входа y и каждого выбора оракульной функции f выход оракула RAM'k' на входе y и при доступе к оракулу f равняется выходу RAMk на входе y;

вероятностная машина RAM'k'

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

Случайная величина, представляющая собой время выполнения вероятностной RAM'k' на входе y полностью определена текущим временем RAMk на входе y.

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

 обозначает модель доступа при забывающем моделировании RAMk на входе y. Тогда  и  идентично распределены, если время выполнения RAMk

на этих входах (т.е., y1

и y2) идентично.

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

Определение 5.11. Для данных вероятностных машин RAM'k'

и RAMk предположим, что вероятностная RAM'k'

моделирует забывающим образом вычисления RAMk

и путь g:N®N - есть некоторая целочисленная функция. Тогда затраты на моделирование являются не больше g, если для каждого y требуемое время выполнения RAM'k' на входе y ограничено сверху g(T)T, где T

обозначает время выполнения RAMk

на входе y.

Модели взаимодействия прикладной программы и программной закладки

Общая модель РПС можно представить в виде совокупности моделей, каждая из которых соответствует описанным выше типам РПС и характеризует действия злоумышленника, исходя из его образа мыслей и возможностей [ПАС].

1. Модель «перехват». Программная закладка встраивается (внедряется) в ПЗУ, ОС или прикладное программное обеспечение и сохраняет все или избранные фрагменты вводимой или выводимой информации в скрытой области локальной или удаленной внешней памяти прямого доступа. Объектом сохранения может быть клавиатурный ввод, документы, выводимые на принтер, или уничтожаемые файлы-документы. Для данной модели существенно наличие во внешней памяти места хранения информации, которое должно быть организовано таким образом, чтобы обеспечить ее сохранность на протяжении заданного промежутка времени и возможность последующего съема. Важно также, чтобы сохраняемая информация была каким-либо образом замаскирована от просмотра легальными пользователями.

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

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

4. Модель «компрометация». Закладка либо передает заданную злоумышленником информацию (например, клавиатурный ввод) в канал связи, либо сохраняет ее, не полагаясь на гарантированную возможность последующего приема или снятия. Более экзотический случай – закладка инициирует постоянное обращение к информации, приводящее к росту отношения сигнал/шум при перехвате побочных излучений.

5. Модель «искажение или инициатор ошибок». Программная закладка искажает потоки данных, возникающие при работе прикладных программ (выходные потоки), либо искажает входные потоки информации, либо инициирует (или подавляет) возникающие при работе прикладных программ ошибки.

6. Модель «сборка мусора». В данном случае прямого воздействия РПС может и не быть; изучаются «остатки» информации. В случае применения программной закладки навязывается такой порядок работы, чтобы максимизировать количество остающихся фрагментов ценной информации. Злоумышленник получает либо данные фрагменты, используя закладки моделей 2 и З, либо непосредственный доступ к компьютеру под видом ремонта или профилактики.

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

Таким образом, исполнение кода закладки может быть сопровождено операциями несанкционированной записи (НСЗ), например, для сохранения некоторых фрагментов информации, и несанкционированного считывания (НСЧ), которое может происходить отдельно от операций чтения прикладной программы или совместно с ними.


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

Возможные комбинации несанкционированных действий (НСЧ и НСЗ), а также санкционированных действий прикладной программы или операционной среды по записи (СЗ) или считыванию (СЧ) приведены в табл. 1.2 [ПАС].

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

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

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

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

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

Ситуация 9 не связана с прямым негативным воздействием, поскольку прикладная программа не активна, а закладка производит только НСЧ (процесс «настройки»).

Ситуация 10 может быть связана с сохранением выводимой информации в оперативную память.

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

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

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

Таблица 1.2

Номер ситуации	НСЧ	НСЗ	Действия РПС	СЧ	СЗ
1	0	0	Нет	0	0
2	0	0	Нет	0	1
3	0	0	Нет	1	0
4	0	0	Нет	1	1
5	0	1	Изменение (разрушение) кода прикладной программы в ОП	0	0
6	0	1	Разрушение или сохранение выводимых прикладной программой данных	0	1
7	0	1	Разрушение или сохранение вводимых прикладной программой данных	1	0
8	0	1	Разрушение или сохранение вводимых и выводимых данных	1	1
9	1	0	Нет	0	0
10	1	0	Перенос выводимых прикладной программой данных в ОП	0	1
11	1	0	Перенос вводимых прикладной программой данных в ОП	1	0
12	1	0	Перенос вводимых и выводимых данных в ОП	1	1
13	1	1	Процедуры типа «размножения вируса» (действия закладки независимо от операций прикладной программы)	0	0
14	1	1	Те же действия, что и в процедурах 6 – 8	0	1
15	1	1	1	0
16	1	1	1	1

<


Ситуации 14 - 16 могут быть связаны как с сохранением, так и с разрушением данных или кода и аналогичны ситуациям 6 - 8.

Несанкционированная запись закладкой может происходить:

·        в массив данных, не совпадающий с пользовательской информацией, - сохранение информации;

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

Следовательно, можно рассматривать три основные группы деструк­тивных функций, которые могут выполняться РПС [ПАС]:

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

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

·     навязывание некоторого режима работы (например, при уничтожении информации - блокирование записи на диск, при этом информация, естественно, не уничтожается) либо замена записываемой информации данными, навязанными закладкой.



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

4. Модель «компрометация». Закладка либо передает заданную злоумышленником информацию (например, клавиатурный ввод) в канал связи, либо сохраняет ее, не полагаясь на гарантированную возможность последующего приема или снятия. Более экзотический случай – закладка инициирует постоянное обращение к информации, приводящее к росту отношения сигнал/шум при перехвате побочных излучений.

5. Модель «искажение или инициатор ошибок». Программная закладка искажает потоки данных, возникающие при работе прикладных программ (выходные потоки), либо искажает входные потоки информации, либо инициирует (или подавляет) возникающие при работе прикладных программ ошибки.

6. Модель «сборка мусора». В данном случае прямого воздействия РПС может и не быть; изучаются «остатки» информации. В случае применения программной закладки навязывается такой порядок работы, чтобы максимизировать количество остающихся фрагментов ценной информации. Злоумышленник получает либо данные фрагменты, используя закладки моделей 2 и З, либо непосредственный доступ к компьютеру под видом ремонта или профилактики.

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

Таким образом, исполнение кода закладки может быть сопровождено операциями несанкционированной записи (НСЗ), например, для сохранения некоторых фрагментов информации, и несанкционированного считывания (НСЧ), которое может происходить отдельно от операций чтения прикладной программы или совместно с ними.


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

Возможные комбинации несанкционированных действий (НСЧ и НСЗ), а также санкционированных действий прикладной программы или операционной среды по записи (СЗ) или считыванию (СЧ) приведены в табл. 1.2 [ПАС].

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

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

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

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

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

Ситуация 9 не связана с прямым негативным воздействием, поскольку прикладная программа не активна, а закладка производит только НСЧ (процесс «настройки»).

Ситуация 10 может быть связана с сохранением выводимой информации в оперативную память.

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

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

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

Таблица 1.2

Номер ситуации	НСЧ	НСЗ	Действия РПС	СЧ	СЗ
1	0	0	Нет	0	0
2	0	0	Нет	0	1
3	0	0	Нет	1	0
4	0	0	Нет	1	1
5	0	1	Изменение (разрушение) кода прикладной программы в ОП	0	0
6	0	1	Разрушение или сохранение выводимых прикладной программой данных	0	1
7	0	1	Разрушение или сохранение вводимых прикладной программой данных	1	0
8	0	1	Разрушение или сохранение вводимых и выводимых данных	1	1
9	1	0	Нет	0	0
10	1	0	Перенос выводимых прикладной программой данных в ОП	0	1
11	1	0	Перенос вводимых прикладной программой данных в ОП	1	0
12	1	0	Перенос вводимых и выводимых данных в ОП	1	1
13	1	1	Процедуры типа «размножения вируса» (действия закладки независимо от операций прикладной программы)	0	0
14	1	1	Те же действия, что и в процедурах 6 – 8	0	1
15	1	1	1	0
16	1	1	1	1

<


Ситуации 14 - 16 могут быть связаны как с сохранением, так и с разрушением данных или кода и аналогичны ситуациям 6 - 8.

Несанкционированная запись закладкой может происходить:

·        в массив данных, не совпадающий с пользовательской информацией, - сохранение информации;

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

Следовательно, можно рассматривать три основные группы деструк­тивных функций, которые могут выполняться РПС [ПАС]:

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

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

·     навязывание некоторого режима работы (например, при уничтожении информации - блокирование записи на диск, при этом информация, естественно, не уничтожается) либо замена записываемой информации данными, навязанными закладкой.

Моделирование на забывающих RAM-машинах

Для каждой приемлемой модели вычислений существует преобразование независимых машин в эквивалентные забывающие машины (т.е., в забывающие машины, вычисляющие ту же самую функцию) [GO,O]. Вопрос заключается в ресурсозатратах для этих преобразований, а именно в определении времени замедления работы забывающей машины. Например, машина Тьюринга с одной лентой может моделироваться посредством забывающей машины Тьюринга с двумя лентами с логарифмическим замедлением времени выполнения. Ниже исследуется подобный процесс, но для модели вычислений с произвольным доступом к памяти (RAM-машины). Основное достоинство RAM-машины – это способность мгновенно получать доступ к произвольным ячейкам памяти. В контексте настоящей работы, приводится следующий основной неформальный результат для RAM-машины [GO,O].

Пусть RAM(m) означает RAM-машину с m ячейками памяти и доступом к случайному оракулу [ГДж]. Тогда t шагов независимой RAM(m)-программы может моделироваться менее чем за O(t(log2 t)3) шагов на забывающей RAM(m(log2 m)2).

Таким образом, можно увидеть, как провести моделирование независимой RAM-программы на забывающей RAM-машине с полилогарифмическим увеличением  размера памяти и полилогарифмическим замедлением времени выполнения. В то же время, простой комбинаторный аргумент показывает, что любое забывающее моделирование независимой RAM-машины должно иметь среднее число W(lоg t) затрат. В связи с эти приводится следующий аргумент.

Пусть машина RAM(m) определена как показано выше. Тогда каждое забывающее моделирование RAM(m)-машины должно содержать не менее max{m,(t-1)log m} операций доступа к памяти при моделировании t шагов оригинальной программы.

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

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

В условиях определения RAM(m)-машины t шагов независимой RAM(m)-программы могут быть промоделированы (доказуемо защищенным от вмешательства способом) менее чем за O(t(log2t)3) шагов на забывающей машине RAM(m(log2m)2).

Необходимо отметить, что вышеприведенные результаты относятся к RAM-машинам с доступом к случайному оракулу. Чтобы получить результаты для более реалистичных моделей вероятностных RAM-машин, необходимо заменить случайный оракул, используемый выше, псевдослучайной функцией. Такие функции существуют в предположении существования односторонних функций с использованием короткого действительно случайно выбранного начального значения (см., например, [Ва1]).

Моделирование с метками времени

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

a и общего числа команд (обозначаемого j), выполненных ЦП, общее число команд «запомнить в ячейку a» может быть эффективно вычислено алгоритмом Q(j,a). Далее рассматривается только моделирование детерминированных RAM-машин.

Определение 5.12. Для данной оракульной машины RAM'k'

и машины RAMk предположим, что оракульная RAM'k'

с доступом к оракулу f' моделирует вычисления RAM'k'. Тогда моделирование является моделированием с метками времени, если существует O(k')-временной алгоритм Q(·,·) такой, что выполняется следующее условие. Пусть (i,a,v) – j-тое сообщение, посланное CPU'k' (в процессе повторных выполнений RAM'k'). Тогда, число предыдущих сообщений формы («запомнить»,a,·), посланных CPU'k', равняется точно (j,a).

Далее отметим, что алгоритм Q(j,a) может вычислить любую версию обращения ЦП

к ячейке памяти а в раунде j. Обозначим номер такой версии как версия(a).

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

-Пороговые схемы

Используемая в данном подразделе (n,t)-пороговая схема, известная как схема разделения секрета Шамира, – это протокол между n+1 участниками, в котором один из участников, именуемый дилер - Д, распределяет частичную информацию (доли) о секрете между n участниками так, что:

·     любая группа из менее чем t участников не может получить любую информацию о секрете;

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

Пусть секрет s

- элемент поля F. Чтобы распределить s

среди участников P1,...,Pn, (где n<÷F÷) дилер выбирает полином fÎF[x] степени не более t-1, удовлетворяющий f(0)=s. Участник Pi

получает si=f(xi) как свою долю секрета s, где xiÎF\{0} – общедоступная информация для Pi (xi¹xj для i¹j).

Вследствие того, что существует один и только один полином степени не менее k-1, удовлетворяющий f(xi)=si для k значений i, схема Шамира удовлетворяет определению (n,t)-пороговых схем. Любые t участников могут найти значение f по формуле:

.

Следовательно

,

где a1,...,ak получаются из

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

Несанкционированное копирование, распространение и использование программ

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

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

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

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

·     возможность получения оперативной консультации;

·     проведение семинаров и курсов по обучению использованию программного продукта;

·     предоставление скидки при покупке следующей версии продукта.

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

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

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY

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

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

Обобщенное описание и типизация РПС

Обобщенное описание и типизация РПС будет делаться в соответствии с работой[ПАС].

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

·     сокрытия признаков своего присутствия в программной среде КС;

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

·     разрушения (искажения произвольным образом) кода программ в оперативной памяти КС;

·     перемещения (сохранения) фрагментов информации из оперативной памяти в некоторые области оперативной или внешней памяти прямого доступа;

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

Можно выделить следующие основные типы РПС.

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

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

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

Существуют три основные архитектуры построения перехватчиков паролей.

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

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

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



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

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

Иногда выделяют особый класс логических бомб - временные бомбы, для которых условием срабатывания является достижение определенного момента времени.

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

Мониторы. Это программные закладки, перехватывающие те или иные потоки данных, протекающие в атакованной системе.


В частности, к мониторам относятся перехватчики паролей второго рода.

Целевое назначение мониторов может быть самым разным:

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

·     искажать потоки данных;

·     помещать в потоки данных навязанную информацию;

·     полностью или частично блокировать потоки данных;

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

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

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

·     сетевой трафик;

·     потоки данных, связанные с удалением информации с дисков или из оперативной памяти компьютера (так называемая «сборка мусора»).

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

Кроме того, РПС можно классифицировать по методу и месту их внедрения и применения, т.е. по «способу доставки» в компьютерную систему (ниже приводится пример персонального компьютера) [ПАС]:

·     РПС, ассоциированные с программно-аппаратной средой компью­терной системы (основная BIOS или расширенные BIOS);

·     РПС, ассоциированные с программами первичной загрузки (нахо­дящиеся в Master Boot Record или ВООТ-секторах активных разделов), - загрузочные РПС;

·     РПС, ассоциированные с загрузкой драйверов DOS, драйверов внешних устройств других ОС, командного интерпретатора, сетевых драйверов, т.е.


с загрузкой операционной среды;

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

·     исполняемые модули, содержащие только код РПС (как правило, внедряемые в файлы пакетной обработки типа .BAT);

·     модули-имитаторы, совпадающие по внешнему виду с некоторыми программами, требующими ввода конфиденциальной информации - наиболее характерны для Unix-систем;

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

·     РПС, маскируемые в программные средства игрового и развлекательного назначения (как правило, используются для первичного внедрения закладок).

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

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

2). РПС должно активизироваться по некоторому общему как для закладки, так и для программы событию, т.е. при выполнении ряда условий в программно-аппаратной среде управление должно быть передано программе-закладке.

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


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

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

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

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

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

Обобщенные модели сбоев и противника

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

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

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

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

Кроме того, противник может быть активным

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

Противник называется t-противником, если он сотрудничает с t

процессорами.

Обоснование критериев принятия решения о наличии в программе РПС

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

Дано:

·          множество Gi

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

·          эталонные значения этих ВХ Gi* и их значения, полученные в результате n испытаний (прогонов) программы.

Необходимо: определить множество Li

таких, что если существует i(½Gi-Gi*½>Li), то делается вывод о наличии в исследуемой программе РПС с вероятностью Р0.

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

Дано: Р=F(y0); q=1-P=P(y>y0); задано число прогонов программы n и значения доверительной вероятности Р0.

Необходимо: определить значение доверительного интервала L

частоты появления события {A-yj<y0}, где yj - j-е значение выходной величины.

Для независимых испытаний частота появления события А-yi<y0 является случайной величиной, распределенной по биномиальному закону с математическим ожиданием Р и дисперсией D=Pq/n. Вероятность появления k событий при n испытаниях в этом случае рассчитывается по формуле  Pk=CnkPkqn-k.

В качестве доверительного интервала [P1*,Р2*] целесообразно выбирать наименьший интервал, вероятность попадания за границы которого больше (1-Р)/2. Границы доверительных интервалов для различных значений Р, Р0 и n сведены в таблицы [Ве], что существенно облегчает задачу инженерного анализа результатов тестирования при контроле технологической безопасности программного обеспечения. С увеличением n биномиальное распределение будет стремиться к нормальному с теми же математическим ожиданием и дисперсией.
При этом для вероятностного тестирования необходимо выбрать такие значения y0, чтобы Р»0,5, что позволяет заменять биномиальное распределение нормальным с максимальной точностью. Доверительный интервал в этом случае определяется по формулам P(½P-P*½<Lэкс)=P0, Lэкс=arg Z*((1+P0)/2), где arg Z* - функция, обратная нормальной функции распределения Z*, полученная по таблицам.

С учетом того, что значение F(y0) вычисляется с точностью d, доверительный интервал L=Lэкс+d, то есть если при проведении испытаний значений Р* будет отличаться от аналогично рассчитанного на величину, большую, чем Lэкс+d, то принимается решение о наличии в исследуемой программе РПС с вероятностью Р0.

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

.

Так как yj представляет собой случайные величины с одинаковым законом распределения, то законы распределения и их суммы стремятся к нормальному с математическим ожиданием m1(y) и дисперсией D(y)/n.

В этом случае доверительный интервал определяется по формуле Lэкс=sarg Z*((1+P0)/2), .

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

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



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

3. Закон распределения входных случайных величин. Для заданного закона распределения аргумента w(x) функции f1(x) и f2(x) будут неразличимы, если для каждой точки y

F(y)=w(x) dx=w(x) dx

или если задаться допустимой точностью вычисления d функции распределения:

½w(x) dx-w(x) dx½£d,

где    Di

- интервалы аргумента, где f1(x)<y;

Dj - интервалы аргумента, где f2(x)<y.

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

Обоснование состава множества информативных характеристик

Выбор информативных ВХ случайных величин Gi

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

·          выбранные ВХ должны существенно изменять свои значения при наличии в программе РПС;

·          ВХ должны относительно легко вычисляться при экспериментальных исследованиях программы.

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

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY

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



где    yi

- значения входной величины при i-том испытании (прогоне программы);

mk*

- начальный момент, полученный при проверке программы;

n - число прогонов программы.

Обоснование выбора модели Нельсона

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

Обозначения и определения для функции дискретного возведения в степень вида gxmoduloM

 Пусть In=Zq представляет собой множество {1,...,q}, где q=j(M) - значение функции Эйлера для модуля M, а Z*M

- множество вычетов по модулю M, где n=élog2Mù. Пусть распределение Dp есть равномерное распределение вероятностей. Оракульной программой, в данном случае, является программа вычисления функции gxmoduloM, по отношению к исследуемым самотестирующейся и самокорректирующейся программам.

Алгоритм Axmodulo N можно вычислить многими способами

[Кн и др.], один из наиболее общеизвестных и применяемых на практике, - это алгоритм, основанный на считывании индекса (значения степени) слева направо. Этот метод достаточно прост и нагляден, история его восходит еще к 200 г. до н.э. Он еще также известен как русский крестьянский метод.

Пусть x[1,...,n] - двоичное представление положительного числа x

и A, B и N - положительные целые числа в r-ичной системе счисления, тогда псевдокод алгоритма Axmodulo N, реализованного программой Exp(?) имеет следующий вид.

Program Exp(x,N,A,R); {вход x,N,A, выход R}

  begin

        B:=1;

        for i:=1 to n do

            begin

               B:=(B*B)modN;

               if [i]=1 then B:=(A*B)modN;

            end;

        R:=B;

  end.

Рис. 4.1. Псевдокод алгоритма AxmoduloN

Из описания алгоритма видно, что число обращений к операции вида (A*B)moduloN будет logx+b(x), где b(x) число единиц в двоичном представлении операнда x или вес Хэмминга x.

Общая характеристика и классификация компьютерных вирусов

Под компьютерным вирусом (или просто вирусом) понимается автономно функционирующая программа, обладающая способностью к самостоятельному внедрению в тела других программ и последующему самовоспроизведению и самораспространению в информационно-вычислительных сетях и отдельных ЭВМ[Без,Бел,ЗМС,ФДК,Со]. Предшественниками вирусов принято считать так называемые троянские программы, тела которых содержат скрытые последовательности команд (модули), выполняющие действия, наносящие вред пользователям. Наиболее распространенной разновидностью троянских программ являются широко известные программы массового применения (редакторы, игры, трансляторы и т.д.), в которые встроены так называемые «логические бомбы», срабатывающие по наступлении некоторого события. Следует отметить, что троянские программы не являются саморазмножающимися.

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

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

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

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

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

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

I. По режиму функционирования:

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

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

II. По объекту внедрения:

·     файловые вирусы

- вирусы, заражающие файлы с программами;

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

В свою очередь файловые вирусы подразделяются на вирусы, заражающие:

·     исполняемые файлы;

·     командные файлы и файлы конфигурации;

·     составляемые на макроязыках программирования, или файлы, содержащие макросы (макровирусы);

·     файлы с драйверами устройств;

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



Загрузочные вирусы подразделяются на вирусы, заражающие:

·     системный загрузчик, расположенный в загрузочном секторе дискет и логических дисков;

·     внесистемный загрузчик, расположенный в загрузочном секторе жестких дисков.

III. По степени и способу маскировки:

·     вирусы, не использующие средств маскировки;

·     stealth-вирусы

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

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

В свою очередь, MtE-вирусы делятся на

·     обычные вирусы-мутанты, в разных копиях которых различаются только зашифрованные тела, а дешифрованные тела вирусов совпадают;

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

Наиболее распространенные типы вирусов характеризуются следующими основными особенностями.

Файловый транзитный вирус

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


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

Наиболее распространенными способами являются инфицирование запускаемых программ, а также файлов при их открытии или чтении. Отличительной особенностью последних является инфицирование загрузочного сектора (бут-сектора) магнитного носителя. Голова бутового вируса всегда находится в бут-секторе (единственном для гибких дисков и одном из двух - для жестких), а хвост - в любой другой области носителя. Наиболее безопасным для вируса способом считается размещение хвоста в так называемых псевдосбойных кластерах, логически исключенных из числа доступных для использования. Существенно, что хвост бутового вируса всегда содержит копию оригинального (исходного) бут-сектора. Механизм инфицирования, реализуемый бутовыми вирусами, например, при загрузке MS DOS, таков. При загрузке операционной системы с инфицированного диска вирус, в силу своего положения на нем (независимо от того, с дискеты или с винчестера производится загрузка), получает управление и копирует себя в оперативную память. Затем он модифицирует вектор прерываний таким образом, чтобы прерывание по обращению к диску обрабатывались собственным обработчиком прерываний вируса, и запускает загрузчик операционной системы. Благодаря перехвату прерываний бутовые вирусы могут реализовывать столь же широкий набор способов инфицирования и целевых функций, сколь и файловые резидентные вирусы.

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

Полиморфные вирусы содержат алгоритм порождения дешифрованных тел вирусов, непохожих друг на друга.


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

Макровирусы распространяются под управлением прикладных программ, что делает их независимыми от операционной системы. Подавляющее число макровирусов функционируют под управлением системы Microsoft Word for Windows. В то же время, известны макровирусы, работающие под управлением таких приложений как Microsoft Word for Windows, Microsoft Exel for Windows, Lotus Ami Pro, Lotus 1-2-3, Lotus Notes, в операционных системах фирм Microsoft и Apple [Бел].

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

Тем самым вирус получает управление и начинает функционировать на ЭВМ-адресате.

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



·     искажение информации в файлах, либо в таблице размещения файлов (FAT-таблице), которое может привести к разрушению файловой системы в целом;

·     имитация сбоев аппаратных средств;

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

·     инициирование ошибок в программах пользователей или операционной системе.

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

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

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

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

·     детекторы;

·     фаги;

·     вакцины;

·     прививки;

·     ревизоры;

·     мониторы.

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

Фаги выполняют функции, свойственные детекторам, но, кроме того, «излечивают» инфицированные программы посредством «выкусывания» вирусов из их тел. По аналогии с полидетекторами, фаги, ориентированные на нейтрализацию различных вирусов, именуют полифагами.

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

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

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

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

Антивирусы рассмотренных типов существенно повышают вирусозащищенность отдельных ПЭВМ и вычислительных сетей в целом, однако, в связи со свойственными им ограничениями, естественно, не являются панацеей.В работе [СМ] приведены основные недостатки при использовании антивирусов.

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

Общая идея

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY

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

Общая номенклатура показателей качества ПО

Номенклатура показателей качества ПО представляет собой систему иерархической структуры, которая отражает логические связи между различными свойствами ПО. Если показатели качества находятся на одном уровне иерархии системы, то свойства, соответствующие этим показателям, соединены логическими связками "И", "ИЛИ". В противном случае либо одно свойство вытекает из другого (логическое следствие), либо свойства логически не зависимы.

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

Описание показателей качества ПО первого уровня приведено в табл. 7.2.

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

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

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

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

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

1). Q1 - множество проявлений показателя качества.

2). Q2 - множество значений показателя качества.

3). Q3 - множество факторов, влияющих на показатель качества.

4). Q4 - множество критериев показателя качества.

Описание этих множеств приведено в табл.7.3.

Таблица 7.2

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

Таблица 7.3

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

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY

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

Общее описание алгоритма «Квадратного корня»

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

к каким виртуальным ячейкам осуществляется доступ и в каком порядке?

сколько раз к конкретной виртуальной ячейке осуществляется доступ (в случае, если к ней обращались)?

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

Алгоритм КК

1. Инициализация:

Первые m+

 слов при моделировании

RAM-машины расположены так, чтобы содержать m виртуальных адресов (к которым оригинальная RAM-машина обращается в процессе выполнения) и

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

2. Моделирование шагов RAM-машины: До тех пор пока моделирование RAM-машины не остановится, выполнить. (Моделирование выполняется за периоды, каждый из которых состоит из

 шагов оригинальной/моделируемой машины). В каждом таком периоде выполняются следующие шаги.

2.1. Случайно переставить содержимое ячеек от 1 до m+

. То есть необходимо равномерно выбрать перестановку p

над целыми числами от 1 до m+

 и забывающим образом переместить содержимое виртуального слова i в фактическое слово pi. Необходимо подчеркнуть, что память зщт (т.е., ячейки от (m++1) до (m+2)) не участвует в этом случайном перемешивании. Таким образом, фактические адреса от 1 до m+называются перемешанной памятью.

2.2. Моделировать

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

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

-     в случае, если i-тое виртуальное слово не найдено в памяти зщт, мы восстанавливаем его из фактического слова p(i), которое является текущей ячейкой i-того виртуального слова в течение этого периода;

-     в противном случае (т.е., в случае, если i-тое виртуальное слово найдено в памяти зщт), мы получаем доступ к следующему «фиктивному слову» в перемешанной памяти (например, мы обращаемся к фактическому адресу p(m+j), где j

- число шагов, моделируемых в текущем периоде);

-     в любом случае модифицируемое значение для i-той виртуальной ячейки записано (забывающим образом) в память зщт

посредством сканирования заново всех слов памяти зщт.

3. Модифицировать перемешанную память. В конце периода, используются значения, сохраненные в памяти зщт

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

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

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



осуществление доступа к   ячейкам перемешанной памяти во время каждого периода. Для каждых возможных  виртуальных операций доступа, последние  фактических операций доступа равномерно распределены среди всех  подмножеств {1,...,m+}, где распределение вероятностей индуцировано выбором перестановки p. Таким образом, фактический доступ, выполняемый на шаге 2, не открывает никакой информации относительно виртуальных операций доступа, выполняемых в этом шаге. Легко увидеть, что шаг 3 не создает никаких новых трудностей, поскольку он может быть сделан при выполнении операций фактического доступа на шагах 1 и 2 в обратном порядке.

Общее описание модели

Ниже рассматривается модель вычислений, которая будет использоваться в дальнейших рассуждениях при исследовании синхронных конфиденциальных вычислений. Таким образом, рассматривается сеть процессоров, функционирование которой синхронизируется общими часами (синхронизатором). Каждое локальное (внутреннее) вычисление соответствует одному моменту времени (одному такту часов). В данной модели отрезок времени между i

и i+1 тактами называется раундом при синхронных вычислениях.

За один раунд протокола каждый процессор может получать сообщения от любого другого процессора, выполнять локальные (внутренние) вычисления и посылать сообщения всем другим процессорам сети. Имеется входная лента «только-для-чтения», которая первоначально содержит строку L(k) (например вида 1k), при этом k является параметром безопасности системы. Каждый процессор имеет ленту случайных значений, конфиденциальную рабочую ленту «только-для-чтения» (первоначально содержащую строку L), конфиденциальную входную ленту «только-для-чтения» (первоначально содержащую строку xi), конфиденциальную выходную ленту «только-для-записи» (первоначально содержащую строку L) и несколько коммуникационных лент. Между каждой парой процессоров i и j существует конфиденциальный канал связи, посредством которого i

посылает безопасным способом сообщение процессору j. Данный канал (коммуникационная лента) исключает запись для i

и исключает чтение дляj. Каждый процессор i

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

Предполагается, что в раунде r

для каждого процессора i

существует однозначно определенное сообщение (возможно пустое), которое распространяет процессор i в этом раунде и для каждой пары процессоров i и j существует единственное сообщение, которое i может безопасным образом послать j

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

Процессор i запускает программу pi, совокупность которых, реализует распределенный алгоритм P. Протоколом работы сети называется n-элементный кортеж P=(p1,p2,..,pn). Протокол называется t-устойчивым, если t процессоров являются сбоящими во время выполнения протокола. Историей

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

во время работы сети.

будет равна R(п)=R=(1-Р)n.

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

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

С учетом введенного определения функциональный разрез должен быть переопределен в терминах вероятностей pji выбора Ei в качестве входных данных при j-том прогоне из некоторой последовательности прогонов. Тогда вероятность того, что j-тый прогон закончится отказом, может быть записана в виде Pi=.

Надежность R(п) программы П равна вероятности того, что в последовательности из п прогонов ни один из них не закончится отказом:

R(n)=(1-Pi)(1-P2)...(1-Pn)=

Эта формула может быть представлена в виде .

Некоторые из свойств функции R(n) могут стать более зримыми при следующих допущениях:

для Pj<<1

,

если Pj=P для всех j, то

R(n)=.

С помощью соответствующих замен переменных и подстановок можно выразить функцию R(n) через время функционирования t. Обозначим через Dtj

время выполнения j-того прогона, через - суммарное время выполнения первых j прогонов программы n примем, что . Тогда .

Если величина Dtj стремится к нулю с ростом n, то сумма в показателе экспоненты становится интегралом и формула для надежности программного обеспечения принимает вид

Эта формула хорошо известна в теории надежности технических устройств. В случае Pj<<1 функция h(tj) может быть интерпретирована как функция интенсивности отказов, которая, будучи умноженной на Dtj,

дает условную вероятность появления отказов и интервале (tj,tj+Dtj) при отсутствии отказов до момента tj.

Общие определения

Следующее определение формализует требования к схеме проверяемого разделения секрета, но в асинхронной установке[BCG].

Определение 3.1. Пусть (АРзПр,АВсПр) - пара многосторонних протоколов таких, что каждый несбоящий процессор, который завершает протокол АРзПр

впоследствии вызывает протокол АВсПр

с локальным выходом протокола АРзПр

как локальным входом. Схема (АРзПр,АВсПр) называется t-устойчивой схемой асинхронного разделения секрета – АПРС для n процессоров, если для каждой коалиции из не более, чем t процессоров и каждого планировщика выполняются следующие условия.

Условие завершения.

1. Если дилер честен, тогда каждый несбоящий процессор, в конечном счете, завершит протокол АРзПр. 2. Если некоторый несбоящий процессор завершил протокол АРзПр, то все несбоящие процессоры, в конечном счете, завершат протокол АРзПр. 3. Если несбоящий процессор завершил протокол АРзПр, то он завершит и протокол АВсПр.

Условие корректности. Как только несбоящий процессор завершил протокол АРзПр, тогда существует уникальное значение r такое, что: 1. все несбоящие процессоры выдают r (а, именно, r - восстанавливаемый секрет); 2. если дилер честен и делит секрет s, тогда r=s.

Условие конфиденциальности.

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

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

неудачно.

В качестве одного из основных математических объектов в данной работе используются односторонние функции, то есть вычислимые функции, для которых не существует эффективных алгоритмов инвертирования. Необходимо отметить, что односторонняя функция - гипотетический объект, поэтому называть конкретные функции односторонними математически некорректно. Впервые такую гипотетическую конструкцию для конкретного криптографического приложения, - открытого распределения ключей, предложили У.Диффи и М. Хеллман в 1976 г. [DH]. Они показали, что вычисление степеней в мультипликативной группе вычетов над конечным полем является простой задачей с точки зрения состава необходимых вычислений, в то время как извлечение дискретных логарифмов над этим полем – предположительно сложная вычислительная задача.

Неформально говоря, для двух независимых множеств X и Y функция f:X®Y называется односторонней, если для каждого xÎX можно легко вычислить f(x), в то время как почти для всех yÎY вычислительно трудно получить такой xÎX, что f(x)=y, при условии , что такой x

существует.

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

Общие положения

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY

Фундаментальный вклад в теорию верификации внес Ч. Хоор, высказавший идеи проведения доказательства частичной правильности программы в виде вывода в некоторой логической системе, а Э. Дейкстра ввел понятие слабейшего предусловия, позволяющее одновременно как соответствие друг другу предусловия и постусловия, так и завершимость. Методы доказательства правильности программ принесли определенную пользу программированию. Было отмечено, что эти методы указывают способ рассуждения о ходе выполнения программ, дают удобную систему комментирования программ и устанавливают взаимосвязи между конструкциями языков программирования и их семантикой. Если принять более широкое толкование термина «анализ программ», подразумевая доказательство разнообразных свойств программ или доказательство теорем о программах, то ценность методов анализа станет более ясной. В частности можно исследовать характер изменения выходных значений программы, количество операций при выполнении программы, наличие зацикливаний, незадействованных участков программы. Таким образом, в некоторых частных случаях методы верификации могут применяться и для доказуемого обнаружения программных дефектов.

Формальное доказательство в виде вывода в некоторой логической системе вполне надежно, но сами доказательства оказываются очень длинными и часто необозримыми. Рассмотрим следующий фрагмент программы [ДДХ].

integer r, dd;

  r:=a; dd:=d;

  while dd£r do dd:=2*dd;

  while dd¹d do

        begin dd:=dd/2;

            if dd£r do r:=r-dd;

        end.

Должно соблюдаться условие, что целые константы a и d удовлетворяют отношениям a³d и d>0.

Рассмотрим последовательность значений, заданную выражениями для:

i=0      ddi=d

i>0      ddi=2*ddi-1.

Далее с помощью обычных математических приемов можно вывести, что:

ddn=d*2n                                                                                                                           (2.1)

Кроме того, поскольку d>0, можно сделать вывод, что для любого конечного значения r отношение ddk>r будет выполняться при некотором конечном значении k; первый цикл завершается при dd=d*2k. Решая уравнение di=2*di-1

относительно di-1, получаем di-1=di/2, что позволяет утверждать, что второй цикл тоже завершится. По окончании первого цикла dd=ddk и поэтому выполняется соотношение

0£r<dd                                                                             (2.2)

Это соотношение сохраняется при выполнении повторяемого оператора второго заголовка. После завершения повторений (в соответствии с заголовком while dd¹d do) мы получаем dd=d. Отсюда и из соотношения 2.2 следует, что

0£r<d                                                                               (2.3)

Далее мы доказываем, что после начала работы программы всегда выполняется отношение:

ddº0(mod d)                                                                    (2.4)

Это следует, например, из того, что возможные значения dd имеют вид (см. 2.1) d*2i при 0£i£k.

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

aºr(mod d)                                                                       (2.5)

Оно выполняется после начальных присваиваний.



Повторяемый оператор первого заголовка (dd:=2*dd) сохраняет отношение 2.5, и поэтому весь первый цикл сохраняет отношение 2.5.

Повторяемый оператор из второго цикла состоит из двух операторов. Первый dd:=2/dd сохраняет инвариантность 2.5; второй тоже сохраняет отношение 2.5, так как он либо не изменяет значение r, либо уменьшает r на текущее dd, а эта операция в силу 2.4 также сохраняет справедливость отношения 2.5. Таким образом, весь повторяемый оператор второго цикла сохраняет отношение 2.5.

Объединяя отношения 2.3 и 2.5, получаем, что окончательное значение r удовлетворяет условиям 0£r<d и aºr(mod d), то есть r - наименьший неотрицательный остаток от деления a на d.

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

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

Почти всегда подобные теоремы формулируются следующим образом [Бей]. «Если конкретное условие истинно непосредственно перед выполнением сегмента программы, тогда после выполнения этого сегмента тоже истинным будет некоторое условие (в общем случае другое)».

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

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

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

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

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

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

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

должно заключаться в том, чтобы ее код был насколько это возможно более простым, то есть Tf

должна быть эффективной в том смысле, что время выполнения Tf

даже с учетом времени, затраченного на вызовы P

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

Пусть p

- означает некоторую вычислительную задачу и/или некоторую задачу поиска решения. Для x, рассматриваемого в качестве входа задачи, пусть p(x) обозначает результат решения задачи p. Пусть Р

– программа (предположительно предназначенная) для решения задачи p, которая останавливается (например, не имеет зацикливаний) на всех входах задачи p. Будем говорить, что Р имеет дефект, если для некоторого входа x задачи p имеет место P(x)¹p(x).

Определим (эффективный) программный чекер Cp

для задачи p следующим образом. Чекер CpP(I,k) – является произвольной вероятностной машиной Тьюринга, удовлетворяющей следующим условиям. Для любой программы P (предположительно решающей задачу p), выполняемой на всех входах задачи p, для любого элемента I задачи p и для любого положительного k (параметра безопасности) имеет место:

·     если программа P не имеет дефектов, т.е. P(x)=p(x) для всех входов x задачи p, тогда CpP(I,k)  выдаст на выходе ответ «Норма» с вероятностью не менее 1-1/2k;

·     если программа P имеет дефекты, т.е. P(x)¹p(x) для всех входов x задачи p, тогда CpP(I,k)  выдаст на выходе ответ «Сбой» с вероятностью не менее 1-1/2k.

Самокорректирующаяся программа

– это вероятностная программа Cf, которая помогает программе P

скорректировать саму себя, если только P

выдает корректный результат с низкой вероятностью ошибки, то есть для любого x, Cf

вызывает программу P для корректного вычисления f(x), в то время как собственно сама P обладает низкой вероятностью ошибки.

Самотестирующейся/самокорректирующейся программной парой называется пара программ вида (Tf,Cf). Предположим, что пользователь может взять любую программу P, которая целенаправленно вычисляет f и тестирует саму себя при помощи программы Tf.


Если P проходит такие тесты, тогда по любому x, пользователь может вызвать программу Cf, которая, в свою очередь, вызывает P

для корректного вычисления f(x). Даже если программа P, которая вычисляет значение функции f некорректно для некоторой небольшой доли входных значений, ее в данном случае все равно можно уверенно использовать для корректного вычисления f(x) для любого x. Кроме того, если удастся в будущем написать программу P¢ для вычисления f, тогда некоторая пара (Tf,Cf) может использоваться для самотестирования и самокоррекции P¢ без какой-либо ее модификации. Таким образом, имеет смысл тратить определенное количество времени для разработки самотестирующейся/ самокорректирующейся программной пары для прикладных вычислительных функций.

Перед тем как перейти к более формальному описанию определений самотестирующихся и самокорректирующихся программ необходимо дать определение вероятностной оракульной программе (по аналогии с вероятностной оракульной машиной Тьюринга).

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

Пусть P - программа, которая предположительно вычисляет функцию f. Пусть I является объединением подмножеств In, где n принадлежит множеству натуральных чисел N и пусть Dp={Dn|nÎN} есть множество распределений вероятностей Dn

над In. Далее, пусть err(P,f,Dn) – это вероятность того, что P(x)¹f(x), где x

выбрано случайно в соответствии с распределением Dn из подмножества In. Пусть b - есть некоторый параметр безопасности. Тогда (e1,e2)-самотестирующейся программой для функции f в отношении Dp с параметрами 0£e1<e2 £1 - называется вероятностная оракульная программа Tf, которая для параметра безопасности b

и любой программы P на входе n имеет следующие свойства:

·     если err(P,f,Dn)£e1, тогда программа TfP выдаст на выходе ответ «норма» с вероятностью не менее 1-b.



·     если err(P,f,Dn)³e2, тогда программа TfP

выдаст на выходе «сбой» с вероятностью не менее 1-b.

Оракульная программа Cf с параметром 0£e<1 называется

e-самокорректирующейся программой для функции f в отношении множества распределений Dp, которая имеет следующее свойство по входу n, xÎIn и b. Если err(P,f,Dn)£e, тогда CfP=f(x) с вероятностью не менее 1-b.

(e1,e2,e)-самотестирующейся/ самокорректирующейся программной парой для функции f

называется пара вероятностных программ (Tf,Cf) такая, что существуют константы 0£e1<e2£e<1 и множество распределений Dp при которых Tf -есть (e1,e2)-самотестирующаяся программа для функции f в отношении Dp и Cf - есть e-самокорректирующаяся программа для функции f в отношении распределения Dp.

Свойство случайной самосводимости.

Пусть xÎIn и пусть c>1 - есть целое число. Свойство случайной самосводимости заключается в том, что существует алгоритм A1, работающий за время пропорциональное nO(1), посредством которого функция f(x) может быть выражена через вычислимую функцию F от x, a1,...,ac и f(a1),...,f(ac) и алгоритм A2, работающий за время пропорциональное nO(1), посредством которого по данному x

можно вычислить a1,...,ac, где каждое ai является случайно распределенным над In в соответствии с Dp.

Общие вопросы

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

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

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

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

Общие замечания

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

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

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

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

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

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

·          обработки исходных текстов и характеристик оттранслированных программ, а также расчета абсолютных и относительных численных характеристик объема модулей программ, числа используемых переменных и констант;

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

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

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

·          диспетчерские программы (верхний уровень иерархии);

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

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY

Широко известны различные программные средства обнаружения элементов РПС - от простейших антивирусных программ-сканеров до сложных отладчиков и дизассемблеров - анализаторов и именно на базе этих средств и выработался набор методов, которыми осуществляется анализ безопасности ПО.

Авторы работ [ЗШ,ПБП] предлагают разделить методы, используемые для анализа и оценки безопасности ПО, на две категории: контрольно-испытательные и логико-аналитические (см. рис.7.1). В основу данного разделения положены принципиальные различия в точке зрения на исследуемый объект (программу). Контрольно-испытательные методы анализа рассматривают РПС через призму фиксации факта нарушения безопасного состояния системы, а логико-аналитические - через призму доказательства наличия отношения эквивалентности между моделью исследуемой программы и моделью РПС.

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

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

Анализ программного обеспечения компонентов КС и процессов его создания показывает [Е1,ЕП,ИБС,Лип0,Лип1,Лип3,Лип4], что эффективность контроля технологической безопасности готовых программ может быть повышена за счет учета специфических особенностей структуры программ и, в частности, параметров, характеризующих сложность проектирования и функционирования готовых программ. К числу параметров, влияющих на сложность проектирования ПО, в первую очередь относятся[Ма]:

·          размер программ, выраженный числом команд и программных модулей в комплексе;

·          количество обрабатываемых переменных и объем памяти для размещения базы данных;

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

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

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

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

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

Оценка надежности программного обеспечения

Надежность машинной программы может быть оценена путем прогона программы на п наборах входных данных и расчета значения оценки R¢

по формуле R¢=1-ne¢/n, где пе

- число наборов входных данных, при которых произошли рабочие отказы.

Если выборка включает п наборов входных данных из Е и осуществляется в соответствии с распределением вероятностей рi, то расчетное значение R¢ будет представлять собой несмещенную оценку надежности R в том смысле, что для рi<<1 ожидаемое значение на всем множестве наборов входных данных в пределах выборки равноR. Это может быть показано, если ввести характеристику выборки zij, которая определяется так, что zij=1, если Еi входит в выборку j и zij=0, в противном случае.

Число различных наборов входных данных nj, входящих в некоторую выборку j, может быть меньше, чем n, так как некоторые наборы Еi могут быть включены в нее более одного раза. Поэтому

=nj.

Однако в большинстве случаев число возможных наборов входных данных N настолько больше размера выборки, что повторный выбор каких-либо наборов маловероятен. Если s - вероятность того, что взята выборка j и M – количество возможных выборок, то

.

Так как R¢

можно представить в виде R¢=

, то математическое ожидание R¢ равно

M(R¢)=

===

=

=.

При р<<1 значение M(R¢)=1-Р=R.

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

Как только вероятности pi определены указанным образом, случайная выборка из n

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

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

являются множество ветвей Lj

(j=1,...,n), подмножества входных наборов данных Gj, соответствующие ветвям Lj, множества сегментов Segj, из которых состоят отдельные ветви, совокупность операторов ветвления, которые обеспечивают переход от одного сегмента к другому при движении по отдельной ветви программы.

Оценка технологической безопасности программ на базе метода Нельсона

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

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

1.     Определение множества E входных массивов.

2.     Выделение в E

подмножеств Gj, связанных с отдельными ветвями программы.

3.     Определение для каждого Gj в предполагаемых условиях функционирования значений вероятности Pj.

4.     Определение подмножества Gj для каждого входного набора данных, используемого в контрольных примерах.

5.     Выявление проверенных пар и непроверенных в ходе испытаний сегментов и пар сегментов.

6.     Определение для каждого j величины P'=ajPj, где aj определяется в соответствии со следующими правилами [ТЛН].

·        aj=0,99, если подмножество Gj

включает более одного контрольного примера;

·        aj=0,95, если подмножество Gj

включает ровно один контрольный пример;

·        aj=0,90, если подмножество Gj

не включает ни одного контрольного примера, но в процессе проверки программы были найдены все сегменты и все сегментные пары ветви Lj;

·        aj=0,80, если в ходе испытаний были опробованы все сегменты, но не все сегментные пары;

·        aj=0,80-0,20m, если m

сегментов (1£m£4) ветви Lj

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

·        aj=0, если более чем 4 сегмента не были опробованы в процессе испытаний.

7. Вычисление грубой оценки R" осуществляется по формуле , где k

представляет собой общее число ветвей программы.

Приведенные выше параметры aj были определены интуитивно [ТЛН] на основе анализа теоретических результатов исследования и экспериментальных результатов тестирования различных программ. Для того, чтобы получить более точные оценки величины R" необходимо провести измерения с использованием подходящего метода формирования выборки.

Оценка технологической безопасности ПО осуществляется посредством проверки условия R"£S", где S" установленная нормативными документами граница безопасности ПО. Отметим также, что для систем критических приложений такая граница должна быть достаточно высокой, то есть стремится к 1.

Оценка значений показателей качества ПО

Методы оценки качества ПО можно подразделить на следующие 6 групп.

1). Общий метод оценки качества ПО КС.

2). Измерительные методы.

3). Экспертные методы.

4). Расчетные методы.

5). Методы принятия решений о качестве ПО.

6). Прочие методы.

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

Как правило, при оценке качества ПО используются комбинация нескольких методов.

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

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

Измерительные методы оценки показателей качества ПО представляют собой совокупность операций по измерению, регистрации, учету, контролю и расчету характеристик и элементов множеств Q1, Q3 и Q4.
Эти методы должны быть ориентированы на получение оценок таких характеристик ПО и результатов его работы, как:

·          состав и количество операторов исходного текста;

·          время работы ПО;

·          число строк комментариев;

·          число операторов и операндов;

·          число исполненных операторов;

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

·          число точек входа/выхода;

·          время реакции;

·          объем ввода/вывода;

·          количество модулей;

·          количество переходов по условию;

·          количество циклов;

·          количество инструкций эксплуатационной документации;

·          количество специфицированных функций;

·          количество внутренних/внешних переменных;

·          время рестарта;

·          объем внутренней/внешней памяти;

·          число сбоев, отказов при работе ПО и другие.

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


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

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

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

1). Подбор и подготовка группы экспертов.

2). Постановка задачи эксперту (экспертам).

3). Контроль работы экспертов.

4). Сбор мнений (оценок) экспертов.

5). Оценка компетентности и добросовестности группы экспертов.

6). Расчет экспертной оценки.

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

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



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

I. Определение альтернативных способов принятия решений.

II. Определение степени неопределенности и риска возможных исходов.

III. Ранжирование предпочтений возможных исходов.

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

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

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

Операции модификации

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

Описание проверяемой схемы разделения секрета

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

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

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

Пусть сеть N состоит из n процессоров P1,P2,...,Pn-1,Pn, где Pn – дилер Д сетиN. Множество секретов обозначается через S, размерность этого множества ½S½=l. Множество случайных параметров, используемых всеми процессорами сети, обозначается через R, размерность ½R½=n. Через W обозначается рабочее пространство параметров сети.

Требуется вычислить посредством выполнения протокола P=(РзПр,ВсПр) функцию f(x),

где f – представляется в виде композиции двух функций g

h. Пусть функция g:(SnÄRnÄW)®W, а функция h:W®S.

Проверяемая схема разделения секрета ПРСК называется

t-устойчивой, если протокол разделения секрета и проверки правильности разделения РзПр и протокол восстановления секрета ВсПр

являются

t-устойчивыми. Функция f является конфиденциально вычислимой, если конфиденциально вычислимы функции g и h.

t-Устойчивая верифицируемая схема разделения секрета ПРСК – есть пара протоколов РзПр и ВсПр, при реализации которых выполняются следующие условия.

Условие полноты. Пусть событие A1 заключается в выполнении тождества

f(w1,...,wn-1,s)=

=g((w1,...,wn-1,s

r),(,...,))=((s1,...,sn-1,wn),(,...,)).

h((s1,...,sn-1),(,...,))=((s,s,...,s,wn),(,...,)).
Тогда для любой константы c>0 и для достаточно больших n вероятность Prob(A1)>1-n-c.
Условие корректности.  Пусть событие A2 заключается в выполнении тождества
f(w1,...,wn-1,s)=
=g((w1,...,wn-1,sr),(,...,))=((s1,...,sn-1,wn),(,...,)).
h((s1,...,sn-1),(,...,))=((u1,...,uj,...,un-1,wn),(,...,)),
где uj=s для jÎG и G – разрешенная коалиция процессоров.
Тогда для любой константы c>0, достаточно больших n, для границы t*<t и любого алгоритма Прот вероятность Prob(A2)<n-c.
Условие конфиденциальности.
Функция g((w1,...,wn-1,sr),(,...,))=((s1,...,sn-1,wn),(,...,)) – конфиденциально вычислима.
Функция h((s1,...,sn-1),(,...,))=((u1,...,uj,...,un-1,s),(,...,)) – конфиденциально вычислима.
Свойство полноты означает, что если все процессоры РзПр
и ВсПр следуют предопределенным вычислениям, тогда любая коалиция несбоящих процессоров может восстановить секрет s. Свойство корректности означает, что при действиях t-противника Прот, любая разрешенная коалиция из n процессоров сети может корректно разделить, восстановить и проверить секрет. Свойство конфиденциальности вытекает из свойства конфиденциальности функции g и h.
Схема ПРСК
Предлагаемая схема ПРСК [GM], является (n/3-1)-устойчивой и использует схему разделения секрета Шамира.
Пусть n=3t+4 и все вычисления выполняются по модулю большого простого числа p>n. Из теории кодов с исправлением ошибок известно, что если мы вычисляем полином f
степени t+1 в

n-1различных точках i, где i=1,...,n-1, тогда по данной последовательности si=f(i), можно восстановить коэффициенты полинома за время, ограниченное некоторым полиномом, даже если t элементов в последовательности произвольно изменены. Это вариант кода Рида-Соломона, известный как код Берлекампа-Велча (см., например, [КС]).


Пусть далее K – параметр безопасности и K/n означает éK/nù.
Протокол РзПр
1.     Дилер Д
выбирает случайный полином f0(x) степени t+1 с единственным условием: f0(0)=s - его секрет. Затем он посылает процессору Pi
его долю si=f0(i). Кроме того, он выбирает 2К случайных полиномов f1,...,f2K степени t+1 и посылает процессору Pi значения fj(i) для каждого j=1,...,2К.
2.     Каждый процессор Pi распространяет (посредством широковещательного канала) K/n случайных битов a(i-1)K/n+j, для j=1,...,K/n.
3.     Дилер Д
распространяет полиномы gj=fj+ajf0 для всех j=1,...,K.
4.     Процессор Pi проверяет, удовлетворяют ли его значения полиномам, распространяемым дилером. Если он обнаруживает ошибку, он ее декларирует для всех. Если более чем t
процессоров сообщают об этом, тогда дилер считается нечестным и все процессоры принимают по умолчанию значение нуля как секрет дилера Д.
5.     Если менее чем t процессоров сообщили об ошибке, дилер распространяет значения, который он посылал в первом раунде тем процессорам, которые сообщали об ошибке дилера.
6.     Каждый процессор Pi распространяет K/n
случайных битов b(i-1)K/n+j для j=1,...,K/n.
7.     Дилер Д
распространяет полиномы hj=fK+j+bjf0 для всех j=1,...,K.
8.     Процессор Pi проверяет, удовлетворяют ли значения, которые он имеет, полиномам, распространяемым дилером Д в 5-м раунде. Если он находит ошибку, он декларирует об этом всем процессорам сети. Если более чем t процессоров сообщают об ошибке, тогда дилер нечестный и все процессоры принимают по умолчанию значение нуля как секрет дилера Д.
Протокол ВсПр
1.     Каждый процессор Pi выбирает случайный многочлен hi степени t+1 такой, что hi(0)=si - его собственная входная доля секрета.


Он посылает процессору Pj значение hi(j).
2.     Каждый процессор Pi выбирает случайные полиномы pi(x), qi,1(x),...,qi,2K(x) степени t+1 со свободным членом 0 и посылает процессору Pj
значения pi(j), qi,1(j),...,qi,2K(j).
3.     Каждый процессор Pi распространяет K случайных битов

gl,(i-1)K/n+m для l=1,...,n и m=K/n.
4.     Каждый процессор распространяет следующие полиномы rj=qi,j+gi,jpi для каждого j=1,...,K.
5.     Каждый процессор Pi проверяет, что информация процессора Pl, посланная ему в 1-м раунде, соответствует тому, что Pl распространяет в 3-м раунде. Если имеется ошибка или Pl распространяет полином с ненулевым свободным членом, процессор Pi распространяет сообщение badl. Если более чем t процессоров распространяют badl, процессор Pl
исключается из сети и все другие процессоры принимают как 0 долю процессора Pl. В противном случае, Pl распространяет информацию, которую он посылал в раунде 1 процессорам, распространявшим сообщение badl.
6.     Каждый процессор Pi распространяет K случайных битов

dl,(i-1)K/n+m для l=1,...,n и m=1,...,K/n.
7.     Каждый процессор Pi распространяет следующие полиномы rj=qi,K+j+di,jpi для каждый j=1,...,K.
8.     Каждый процессор Pi проверяет, что информация, посланная процессором Pl, в 1-м раунде и распространенная в 5-м раунде соответствует полиномам процессора Pl, распространенным в 7-м раунде. Если имеется ошибка или Pl распространил полином с ненулевым свободным членом процессор Pi распространяет badlr. Если более чем t
процессоров распространили badl, тогда Pl – нечестен и все процессоры принимают его долю, равную 0.
9.     Каждый процессор Pl распределяет всем другим процессорам следующее значение si+p1(i)+p2(i)+...+p(i), затем интерполирует полином F(x)=f0(x)+p1(x)+p2(x)+...+pn(x) c использованием алгоритма с исправлением ошибок Берлекампа-Велча.Секрет будет равен s=F(0)=f(0).
Заметим, что если дилер Д честен, в конце протокола ВсПр противник, даже зная секрет s и t долей «подкупленных» процессоров, ничего не узнает о долях секрета несбоящих процессоров, так как полином имеет степень t+1, а ему необходимо для интерполяции t
+2 точки.

Описание способов проведения испытаний, оценки качества и сертификации программных средств

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

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

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

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

Оценка качества ПО может осуществляться при проведении следующих видов работ:

·

определение технических требований к разрабатываемым ПО;

·          контроль качества на отдельных этапах разработки ПО;

·          испытания и демонстрация работ ПО;

·          контроль качества в процессе производства ПО;

·          контроль качества при приеме-сдаче и купле-продаже ПО;

·          контроль качества и планирование работ при сопровождении ПО;

·          принятие решения о снятии ПО с эксплуатации, прекращении производства, разработки.

Определение характеристик взаимосвязи

Характеристики иерархической структуры и взаимосвязей модулей между собой в процессе решения задач КУП определяются на основе:

·

анализа блок-схемы комплекса с выделением глобальных переменных, используемых в программах;

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

·          вычисления числа переменных в программных модулях, количества условных переходов и циклов в программах.

В процессе анализа блок-схемы комплекса программ определяется количество уровней иерархии структуры комплекса (r), распределение числа программ по уровням P1(r) и распределение среднего количества команд в программах различных уровней P2(r).

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

Взаимосвязь модулей комплекса программ между собой характеризуются распределением числа вызываемых программ P3(r) и распределением числа программ, обращающихся к анализируемой программе - P4(r). Подсчет сложности взаимодействия модулей выполняется с учетом всех управляющих и информационных связей путем интегрирования характеристик модулей. Для каждого i-го модуля число путей входа в него или число модулей, откуда он вызывается, характеризуется величиной aij входных управляющих связей. Аналогично число выходных управляющих связей можно представить как число модулей bij, вызываемых из данного. Наименьшая связность реализуется, когда i-й модуль сопрягается только с одним j-м программным модулем и имеет одну входную (aij=1) и одну выходную (bij=1) связи. В этом случае модуль не вызывает другие модули, а только возвращает управление после завершения своей функции. В результате i-тый модуль находится на нижнем уровне в данной ветви комплекса программ, так как он не вызывает других модулей.

В общем случае сложность управляющих связей для i-того модуля можно представить суммой:

.
Тогда сложность связей группы программ имеет вид: , где суммирование идет по всем модулям, входящим в группу.

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

Информационные связи между модулями анализировать сложнее, чем управляющие. Это обусловлено тем, что возможны, с одной стороны, информационные связи между модулями, непосредственно не связанными по управлению, а с другой стороны - тем, что каждая информационная связь может характеризоваться различным числом и типом переменных, участвующих в обмене. В первом приближении информационная связь i-того и j-того модулей может быть оценена количеством глобальных и обменных переменных с одинаковыми именами, используемых в планируемой паре модулей. Степень зависимости каждого модуля от остальных можно характеризовать количеством типов (индекс k) переменных aij на входе, необходимых для нормального функционирования данного модуля: .

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

Переменные, которые используются i-тым модулем не модифицируясь, является только входными и не учитываются как выходные связи.

Таким образом, количественно охарактеризовать информационные связи i-того модуля можно следующим образом: =Ai+Bi.

Полное количество информационных связей в группе программ равно сумме связей модулей =Ai+Bi.

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


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

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

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

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

Определение модели надежности программного обеспечения

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

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

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

Организационные вопросы проведения испытаний ПО

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

·

разработчика (в процессе создания ПО);

·          заказчика (фондодержателя) при приеме-сдаче ПО (прием в Фонд алгоритмов и программ - ФАП) и при подготовке к разработке ПО;

·          изготовителя при производстве ПО;

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

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

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

Основной протокол

Пусть f:Fn®F – арифметическая схема A. Нижеприведенный протокол безопасно t-вычисляет функцию f.

Протокол АВФ

Код для процессора Pi по локальному входу xi  и данной схеме A.

1. Установить (t,xi)АГПРС=(C,{si,j½jÎC}). Для линии l в схеме пусть l(i) определяет долю процессора Pi, находящуюся на этой линии. Если l

– j-тая входная линия схемы, тогда установить l(i)=si,j, если jÎG и l(i)=0 в противном случае.

2. Для каждого вентиля g в схеме, процессор Pi ожидает, пока i-тые доли всех входных линий вентиля g будут вычислены. Тогда он делает следующее.

2.1. Если g – аддитивный вентиль с выходной линией l и входными линиями l1

и l2, тогда вычисляет l(i)=l1(i)+l2(i).

2.2. Если g – аддитивный вентиль l=l1·l2, тогда вычисляет l(i)=MUL(l1(i),l2(i)).

3. Пусть lout – выходная линия схемы. Как только значение  l(i)out – вычислено, послать сообщение «Готово» всем другим процессорам.

4. Дождаться получения n-t сообщений «Готово» от других процессоров. Установить (t,n,l(i)out)Авс=y.

Подать на выход (C,y).

 

Теорема 3.8. Пусть

f:Fn®F для некоторого поля F

с |F|>n и пусть A – схема, вычисляющая функцию f. Тогда протокол АВФ асинхронно

(én/3ù-1)-безопасно вычисляет f в модели с ограничено защищенными каналами в условиях проявления FS-сбоев.

Доказательство.

Приведено в работе [Ca2].

Основной результат для злонамеренной модели

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

Теорема 3.3.

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

Эта теорема устанавливает возможность компиляции любого протокола для получестной модели в «эквивалентный» протокол для злонамеренной модели. Существование таких компиляторов показано в ряде работ (см., например, [Ca1,Ca2,Go1]. Сам процесс построения компиляторов для целей, необходимых для построения наших протоколов, является достаточно сложным, и использует в качестве инструментальных средств («крупных примитивов») такие схемы как: схемы привязки, системы доказательств с нулевым разглашением для NP-утверждений, для NP-свидетельств и др. [Go1].

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

Теорема3.6.

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

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

Основные функции средств защиты от копирования

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

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

·

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

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

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

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

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

Для снятия защиты от копирования применяют два основных метода: статический и динамический [РД].

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

Основные определения и обозначения

Пусть АУТ(m) - обычный (оригинальный) алгоритм аутентификации сообщений и АУТa(m)- функция маркирования сообщения m, индуцированная схемойАУТ с ключом аутентификации a. Пусть ВЕРa(m,b) - соответствующий алгоритм верификации, где b={true, false} – предикат корректности проверки.

Далее будут использоваться деревья поиска и, следовательно, необходимо напомнить, что 2-3-дерево имеет все концевые узлы (листья) на одном и том же самом уровне/высоте (как и в случае сбалансированных двоичных деревьев) и каждая внутренняя вершина имеет или 2, или 3 дочерних узла [АХУ]. В данном случае 2-3-дерево подобно двоичному дереву является упорядоченным деревом и, таким образом, концевые узлы являются упорядоченными. Пусть Vh

– определяет множество всех строк длины не больше h, ассоциированных очевидным образом с вершинами сбалансированного 2-3-дерева высоты h. Маркированное дерево может рассматриваться как функция Т: Vh®{0,1}*, которая приписывает аутентификационный признак (АП) каждой вершине.

Пусть совокупный аутентификационный признак файла F получен посредством использования 2-3-дерева аутентификационных признаков для каждого из блоков файла F=F[1],...,F[l] (далее такое дерево будет называться маркированным деревом). Каждая вершина w ассоциирована с меткой, которая состоит из АП (аутентифицирующих дочерние узлы) и счетчика, представляющего число узлов в поддереве с корнем w.

Основные предположения и ограничения

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

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

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

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

При этом необходимо учитывать два фактора:

·

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

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

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

·     достаточным условием для отнесения РПС к классу компьютерных вирусов является наличие в его составе процедуры саморепродукции;

·     достаточным условием для отнесения РПС к классу средств несанкционированного доступа являются наличие в его составе процедуры преодоления защиты и отсутствия процедуры саморепродукции;

·     достаточным условием для отнесения РПС к классу программных закладок является отсутствие в его составе процедур саморепродукции и преодоления защиты.

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

·     процедуры захвата (получения) управления;

·     процедуры самомодификации («мутации»);

·     процедуры порождения (синтеза);

·     процедуры маскировки (шифрования).

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

Основные принципы обеспечения безопасности ПО

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

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

---

---