WWW.DISSERS.RU

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

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

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |

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

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

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

Булева переменная found будет инициироваться, если требуемое значение найдено в памяти зщт. Когда оригинальная RAM-машина осуществляет доступ к i-тому виртуальному слову, забывающая RAM-машина работает следующим образом:

• (2a) сканирует полностью память зщт и ищет виртуальный адрес i.

m m А именно, для j, пробегающему значения от m+ +1 до m+2, доступ к фактической ячейке памяти j переменная found устанавливается в true и сохраняется в ЦП, если виртуальный адрес i совпадает с фактической ячейкой j. (Переменная found инициализирована в значение false до этого сканирования и остается такой же, если виртуальный адрес i не был найден);

• (2b) если found=false, тогда забывающая RAM-машина осуществляет доступ к слову с меткой (i) и сохраняет содержимое в ЦП. Как показано выше, это реализуется посредством двоичного поиска метки (i);

• (2c) если found=true, тогда забывающая RAM-машина осуществляет доступ к слову с меткой (m+счт), которое является макетом. Это также реализуется посредством двоичного поиска метки (m+счт);

• (2d) просматривает полностью память зщт снова и записывает модифицируемое значение i-того виртуального слова в памяти зщт.

m m А именно, для m+ +1 до m+2 доступ к фактической ячейке памяти j запоминается в ее модифицированном значении виртуального адреса i, если адрес j содержит старое значение виртуального адреса i (т.е., found=true), либо found=false и j - первое пустое слово в памяти зщт.

• Значение счт увеличивается на 1.

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

5.7.4. Анализ алгоритма «Квадратного корня» Как обсуждалось выше, последовательность фактических операций доступа к памяти забывающей RAM-машины действительно не открывает никакой информации относительно последовательности виртуальных операций доступа к памяти оригинальной RAM-машины. Это действительно так, потому что во время шагов 1, 2a, 2d и 3 фактическая модель доступа фиксирована, в то время как во время шагов 2b и 2c фактические модели доступа неразличимы и «случайны».

Теперь остается вычислить затраты на моделирование (т.е., отношение числа операций доступа, выполненных на забывающей RAM машиной к числу оригинальных операций доступа). Далее мы вычисляем общее число фактических операций доступа, выполняемых на период m (т.е., m+2 виртуальных операций доступа). Число фактических операций доступа на шаге 1 определено числом сравнений в сортирующей сети Батчера, а именно, O(mlog2m). То же самое делается на шаге 3. Что касается шага 2, каждая виртуальная операция доступа выполняется за m m m 2 +log2(m+ )=O( ) фактических операций доступа. Это составляет m амортизационные затраты O(log2m ). Фактически, вышеупомянутый выбор параметров (то есть, размер памяти зщт) не оптимален.

При использовании памяти зщт размера s, мы получаем амортизационные затраты O(m log2 m) + (2s + 1 + log m), s m которые минимизированы установкой s=(logm ).

5.8. ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ В данной главе был представлен компилятор, который трансформировал RAM-программы в эквивалентные программы, которые предотвращают попытки противника выяснить что-либо относительно этих программ при их выполнении. Перенос был выполнен на уровне команд, а именно операции доступа к памяти для каждой команды заменялись последовательностью избыточных операций доступа к памяти.

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

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

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

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

ГЛАВА 6. КРИПТОПРОГРАММИРОВАНИЕ 6.1. КРИПТОПРОГРАММИРОВАНИЕ ПОСРЕДСТВОМ ИСПОЛЬЗОВАНИЯ ИНКРЕМЕНТАЛЬНЫХ АЛГОРИТМОВ Одним из основных инструментов методологии криптопрограммирования являются инкрементальные криптографические алгоритмы. Цель инкрементальной криптографии заключается в разработке криптографических алгоритмов обработки электронных данных, обладающих следующим принципиальным свойством. Если алгоритм применяется к электронным данным D для достижения каких либо их защитных свойств, то применение инкрементального алгоритма к данным D, подвергнувшихся модификации – D, должно осуществляться быстрее, чем необходимость заново обработать первоначальный электронный документ. В тех приложениях, когда указанные алгоритмы используют, например, алгоритмы шифрования электронных документов или их цифровой подписи, требование повышения эффективности инкрементальных алгоритмов является основным. Один из основных методов применения инкрементальных алгоритмов заключается в использовании их аутентификационных признаков для антивирусной защиты [BGG].

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

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

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

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

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

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

6.2. ОСНОВНЫЕ ЭЛЕМЕНТЫ ИНКРЕМЕНТАЛЬНОЙ КРИПТОГРАФИИ 6.2.1. Базовые примитивы Инкрементальность можно рассматривать для любого криптографического примитива. В данном случае рассматриваются два из них – цифровая подпись и шифрование. Инкрементальность далее рассматривается, как правило, для «прямых» преобразований, а именно для генерации подписи и шифрования, но все рассуждения будут верны и для «сопряженных» преобразований, а именно для верификации подписи и дешифрования.

6.2.2. Операции модификации При рассмотрении проблемы модификации защищаемого файла в терминах применения фиксированного набора основных операций по модификации электронного документа исследуются следующие операции модификации: замена блока в документе другим;

вставка нового блока;

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

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

Чтобы избежать таких затрат необходимо использовать схемы, свободные от истории или HF-схемы. Все нижеприведенные схемы являются схемами, свободными от истории.

6.2.4. Безопасность Свойство инкрементальности вводит новые проблемы безопасности [Ва3], а, следовательно, «назревает» необходимость новых определений. Рассмотрим случай схем подписи или аутентификации сообщений. Разумно предположить, что противник не только имеет доступ к предыдущим подписанным версиям фалов, но также способен выдавать команды на модификацию текста в существующих файлах и получать инкрементальные подписи для измененных файлов. Такая атака на основе выбранного сообщения (см. приложение) для инкрементальных алгоритмов подписи может вести к «взлому» используемой оригинальной схемы подписи, которая не может быть взломана при проведении противником атак, когда инкрементальные алгоритмы не используются.

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

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

6.3. МЕТОДЫ ЗАЩИТЫ ДАННЫХ ПОСРЕДСТВОМ ИНКРЕМЕНТАЛЬНЫХ АЛГОРИТМОВ МАРКИРОВАНИЯ 6.3.1. Инкрементальная аутентификация Основные определения и обозначения Пусть АУТ(m) - обычный (оригинальный) алгоритм аутентификации сообщений и АУТ(m)- функция маркирования сообщения m, индуцированная схемой АУТ с ключом аутентификации. Пусть ВЕР(m,) - соответствующий алгоритм верификации, где ={true, false} – предикат корректности проверки.

Далее будут использоваться деревья поиска и, следовательно, необходимо напомнить, что 2-3-дерево имеет все концевые узлы (листья) на одном и том же самом уровне/высоте (как и в случае сбалансированных двоичных деревьев) и каждая внутренняя вершина имеет или 2, или дочерних узла [АХУ]. В данном случае 2-3-дерево подобно двоичному дереву является упорядоченным деревом и, таким образом, концевые узлы являются упорядоченными. Пусть Vh – определяет множество всех строк длины не больше h, ассоциированных очевидным образом с вершинами сбалансированного 2-3-дерева высоты h. Маркированное дерево может рассматриваться как функция Т: Vh{0,1}*, которая приписывает аутентификационный признак (АП) каждой вершине.

Пусть совокупный аутентификационный признак файла F получен посредством использования 2-3-дерева аутентификационных признаков для каждого из блоков файла F=F[1],...,F[l] (далее такое дерево будет называться маркированным деревом). Каждая вершина w ассоциирована с меткой, которая состоит из АП (аутентифицирующих дочерние узлы) и счетчика, представляющего число узлов в поддереве с корнем w.

Алгоритм маркирования Алгоритм создания 2-3-дерева аутентификационных признаков (алгоритм маркирования) работает следующим образом.

Алгоритм САП2- 1. Получить для каждого i, признак (,F[i])АУТ=(T(w)), где w – i-тый концевой узел.

2. Получить для каждого неконцевого узла w, признак (,(L1,L2,L3),рзм)АУТ=(Т(w)), где Li - метка i-того дочернего узла w (в случае, если w имеет только два дочерних узла, то L3=) и рзм - число узлов в поддереве с корнем w).

3. Получить для корня дерева признак (,(L1,L2,L3),Id,счт)АУТ=(Т()), где Id - название документа и счт – соответствующее показание счетчика (связанное с этим документом).

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

Алгоритм ИАМ2- Пусть u0,...uh - путь из корня u0= к j-тому концевому узлу обозначается как uh. Тогда:

1. Проверить, что алгоритм ВЕР при верификации принимает Т() как корректный АП строки (,(L1,L2,L3),Id,счт)АУТ=Т(), где Id - название документа и счт - текущее значение счетчика (связанного с этим документом).

2. Для i=1,...,h-1 проверить, что ВЕР принимает Т(ui) как корректный АП строки ((L1,L2,L3),рзм), где Li - метка i-того дочернего узла w (в случае, если w имеет только два дочерних узла, то L3=) и рзм - число узлов в поддереве с корнем w)).

3. Проверить, что ВЕР принимает Т(uh) как корректный АП блока F[j].

4. Если все эти проверки успешны, тогда совокупный АП файла F получается следующим образом.

4.1. Установить Т(uh):=АУТ(F()).

4.2. Для i=h-1,...,1 установить Т(ui):=АУТ(Т(ui1),Т(ui2),Т(ui3)).

4.3. Установить Т():=АУТ((Т(ui0),Т(ui1),Т(ui1)),Id,счт+1).

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

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

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

6.3.2. Инкрементальное шифрование Вводные замечания Будем говорить, что инкрементальное шифрование является стойким относительно некоторой операции модификации, если (для данной последовательности шифртекстов Е1,...,Et над соответствующими открытыми данными Di, i=1,...,t и при инкрементальном получении каждой последовательности Еi, из предыдущих шифртекстов Ei-1) извлечение какой-либо информации об оригинальном документе D1, также как и его измененных версиях D2,.., Dt (за исключением того факта, что Di получено посредством применения этой операции модификации к открытым данным Di-1) не возможно. Аналогично, рассмотрим любые две последовательности А=(А1,...,Аt) и В=(В1,...,BB ) так, что A1,BB l, где - t используемый алфавит. Данные Аi (отн., Вi) получены заменой единственного символа в Ai-1 (отн., Вi-1). Тогда, не должны быть различимы последовательность шифртекстов, полученных посредством применения инкрементального алгоритма I при обработке «командой создания» блока данных A1 и соответствующих «команд замены» в последовательности А, от последовательности шифртекстов, полученных посредством применения инкрементального алгоритма I при обработке «команды создания» блока данных В1 и соответствующих «команд замены» данных В.

Схемы инкрементального шифрования Предлагаемые решения используют стойкую схему вероятностного шифрования E [GM] (см. также приложение). Предположим, что Е может использоваться для шифрования символов из и пар (i,), где и i - целое число не большее, чем длина блоков данных в системе. При использовании Е сначала будет описан алгоритм, который шифрует версии блоков данных, в которых осуществляется операции замены. Далее будем рассматривать операцию замены одного символа. Шифрованные версии состоят из двух последовательностей шифртекстов, обозначаемых Е1 и Е2.

Первая последовательность Е1 является результатом блочного шифрования некоторого файла D=D[1]...D[l], в то время как вторая Е2, шифрует последовательность изменений, обозначаемую M=М[1]...M[t], посредством которых текущий документ был получен из D. Тогда инкрементальный алгоритм шифрования заключается в конкатенации шифртекста модифицированного документа с Е2. Каждые l шагов алгоритм восстанавливает модифицированные данные и заново шифрует их, используя блочное шифрование и, таким образом, формирует новую последовательность шифртекстов Е1 (одновременно устанавливая Е2 в нулевую последовательность). Сложность этого алгоритма составляет два блочных шифрования на каждое изменение. Важным моментом является то, что конвейерная обработка является достаточно ресурсозатратной.

Теперь предположим, что нам позволено сохранять промежуточные результаты работы в некоторой безопасной памяти («невидимой противником»). В этом случае, как только длина Е2 достигнет l, мы можем начать подготовку новых шифртекстов для данных, обозначаемых D', которые получаются D применением первых l изменений в М. Для этого необходимо выполнить все требуемые вычисления наряду со следующими l изменениями, в то время как М увеличивается до размера 2l. Таким образом, мы имеем шифртекст, обозначаемый Е' данных D' (конечно, теперь текущие данные другие). При замене Е1 на Е' и при исключении первых l изменений в М мы получаем зашифрованную форму текущего документа. Следует подчеркнуть, что в такой модели вычислений все эти операции могут выполняться за константное временя. Наконец необходимо отметить, что алгоритм работает в периодах, каждый состоящий из l изменений. В каждом периоде, алгоритм модифицирует шифртекст для сравнения с изменениями, выполненными в предыдущем периоде.

Выше мы предположили, что пользователь может хранить промежуточные результаты (которые требуют памяти размером О(l)) в локальной памяти, невидимой противником. Это предположение нереалистично в некоторых сценариях и несовместимо с вышеприведенными определениями для схем инкрементального шифрования. Далее мы используем вышеупомянутые идеи без этого предположения (идеи берутся из [GO,O], см. предыдущую главу). Для этого нам необходимо шифровать данные, используя три последовательности, обозначаемые Е1,Е2 и Е3. Первые две последовательности Е1 и Е2, является точно такими же, как определенные выше. Их достаточно для дешифрования данных. Дополнительная последовательность Е3 – является «шифрованием рабочей области» и обозначается как W=W[1]...W[2l].

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

Сначала, мы устанавливаем элементы последовательности W следующим образом: W[i]:=(i+D[i]) для il и W[i]:=M[i-l] для l+1i2l.

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

Определяющим является то, что сортировка выполняется посредством использования эффективной сети сортировки такой, например, как сеть сортировки Батчера [BGG]. Следует подчеркнуть, что всякий раз, когда две пары сравниваются и переставляются (или нет), тогда они заново шифруются посредством Е (так что противник не может «понять» были ли они переставлены или нет). Это гарантирует то, что вся процедура сортировки не дает никакой информация противнику. Как только сортировка завершена, алгоритм просматривает W для нахождения всех мест нахождения элементов с одним и тем же ключом сортировки и сохраняет последнее (которое является новым), в большом фиктивном значении (l+1,...). Теперь, мы посредством ключа сортировки заново сортируем пары из W и получаем последовательность, в которой первые l элементов содержат модифицированный документ D'. В заключение, мы устанавливаем Е1 для хранения в ней зашифрованного блока данных D' и исключаем первые l элементов последовательности Е2.

При использовании AKS-сети сортировки [BGG] вышеприведенная реализация инкрементального алгоритма шифрования требует O(llog l) шагов (в то время как, если мы используем сеть Батчера, то получаем сумму из О(l)+(llоg2l) шагов). Эти шаги могут быть распределены равномерно среди l операций модификации, обеспечивающих желаемую сложность.

Как было упомянуто выше, каждый из рассматриваемых алгоритмов можно адаптировать для реализации схемы инкрементального шифрования для операций вставки/удаления (единственного символа), которая является эффективной в строгом смысле. Для этого длина открытых данных устанавливается в некоторых предопределенных пределах (например, между l/2 и 2l). А именно, схема инкрементального шифрования состоит из трех последовательностей Е1, Е2 и Е3, где Е1 и Е2 – определены выше, а Е3 - шифрование рабочей области для некоторого забывающего моделирующего устройства (см. предыдущую главу). Также как и как выше, алгоритм работает в периодах, состоящих из l изменений каждый. В каждом периоде, инкрементальный алгоритм выполняет l изменений предыдущего периода. Это делается посредством моделирования RAM программы, которая содержит структуру данных, обеспечивающую эффективное выполнение операций вставки/удаления, например, 2-3 дерево.

6.4. ВОПРОСЫ СТОЙКОСТИ ИНКРЕМЕНТАЛЬНЫХ СХЕМ Обеспечение безопасности в традиционных схемах подписи и шифрования сводится к исследованию поведения противника, который, не зная секретного ключа, пытается осуществить злоумышленные действия в отношении этих схем. Например, в схемах подписи, в том числе, требуется, чтобы противник, не зная ключа, не мог бы подделывать подписи.

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

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

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

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

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

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

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

Пусть каждый защищаемый файл вместе с деревом аутентификационных признаков хранится в общедоступной памяти. При подходящем выборе сложностных параметров затраты памяти для хранения дерева АП могут быть незначительными по отношению к самому файлу. Например, мы можем разделить файл на блоки длины s2, где s - длина АП (и соответствующего ключа) базовой схемы аутентификации сообщений). Для L-битного файла, мы получим дерево АП с L/s2 ветвями, которое может быть закодировано двоичной строкой размером O(L/s). Для каждого файла пользователю необходимо хранить только O(s) битов в локальной защищенной памяти. Эти биты используются для хранения ключа схемы аутентификации, имени файла и текущего счетчика версий.

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

Базовая схема аутентификации сообщений может быть любой из стандартных. Например, режим генерации имитовставки алгоритма ГОСТ 28147-89 или любые схемы аутентификации, использующие псевдослучайные функции [Ва1].

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

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

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

Однако идеи, используемые для защиты программ (в смысле предыдущего раздела и [GO,O]) можно адаптировать для получения инкрементальной схемы шифрования для операций вставки/удаления (единственного символа), которые является эффективным в строгом смысле, т.е. как число шагов моделирования на одну оригинальную операцию. Адаптация достигается «конвейерной обработкой», описание которой дано выше.

ГЛАВА 7. МЕТОДЫ И СРЕДСТВА АНАЛИЗА БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 7.1. ОБЩИЕ ЗАМЕЧАНИЯ Широко известны различные программные средства обнаружения элементов РПС - от простейших антивирусных программ-сканеров до сложных отладчиков и дизассемблеров - анализаторов и именно на базе этих средств и выработался набор методов, которыми осуществляется анализ безопасности ПО.

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

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

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

7.2. КОНТРОЛЬНО-ИСПЫТАТЕЛЬНЫЕ МЕТОДЫ АНАЛИЗА БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Контрольно-испытательные методы - это методы, в которых критерием безопасности программы служит факт регистрации в ходе тестирования программы нарушения требований по безопасности, предъявляемых в системе предполагаемого применения исследуемой программы [ЗШ]. Тестирование может проводиться с помощью тестовых запусков, исполнения в Методы и модели анализа безопасности программ Логико-аналитические Контрольно-испытательные Методы контроля Модель программы выполнения программы и РПС Формальный аппарат Средства контроля за доказательства выполнением программ безопасности Средства анализа и Самоконтролирующиеся преобразования программ среды Средства порождения моделей РПС Методы контроля состояния среды Средства преобразования моделей и определения отношений между ними Средства анализа безопасности программ Рис. 7.1. Методы и средства анализа безопасности ПО виртуальной программной среде, с помощью символического выполнения программы, ее интерпретации и другими методами.

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

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

Пусть задано множество ограничений на функционирование программы, определяющих ее соответствие требованиям по безопасности в системе предполагаемой эксплуатации. Эти ограничения задаются в виде множества предикатов С={ci(a1,a2,...am)|i=1,...,N} зависящих от множества аргументов A={ai|i=1,...,M}.

Это множество состоит из двух подмножеств:

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

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

Для доказательства того, что исследуемая программа удовлетворяет требованиям по безопасности, предъявляемым на предполагаемом объекте эксплуатации, необходимо доказать, что программа не нарушает ни одного из условий, входящих в С. Для этого необходимо определить множество параметров P={pi|i=1,...,K}, контролируемых при тестовых запусках программы. Параметры, входящие в это множество определяются используемыми системами тестирования. Множество контролируемых параметров должно быть выбрано таким образом, что по множеству измеренных значений параметров Р можно было получить множество значений аргументов А.

После проведения Т испытаний по вектору полученных значений параметров Pi,i=1,...,T можно построить вектор значений аргументов Ai, i=1,...,T.

Тогда задача анализа безопасности формализуется следующим образом.

Программа не содержит РПС, если для любого ее испытания i=1,...,T множество предикатов C={cj(a1i,a2i...aMi)|j=1,...,N} истинно.

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

Рассмотрим схему анализа безопасности программы контрольно испытательным методом (рис.7.2).

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

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

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

7.3. ЛОГИКО-АНАЛИТИЧЕСКИЕ МЕТОДЫ КОНТРОЛЯ БЕЗОПАСНОСТИ ПРОГРАММ При проведении анализа безопасности с помощью логико аналитических методов (см. рис.7.3) строится модель программы и формально доказывается эквивалентность модели исследуемой программы и модели РПС. В простейшем случае в качестве модели программы может выступать ее битовый образ, в качестве моделей вирусов множество их сигнатур, а доказательство эквивалентности состоит в поиске сигнатур вирусов в программе. Более сложные методы используют формальные модели, основанные на совокупности признаков, свойственных той или иной группе РПС.

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

Выбирается некоторая система моделирования программ, представленная множеством моделей всех программ - Z. В выбранной системе исследуемая программа представляется своей моделью М, принадлежащей множеству Z. Должно быть задано множество моделей РПС V={vi|i=1,...,N}, полученное либо путем построения моделей всех известных РПС, либо путем порождения множества моделей всех возможных (в рамках данной модели) РПС. Множество V является подмножеством множества Z. Кроме того, должно быть задано отношение эквивалентности определяющее наличие РПС в модели программы, обозначим его Е(x,y). Это отношение выражает тождественность программы x и РПС y, где x - модель программы, y - модель РПС, и y принадлежит множеству V.

Тогда задача анализа безопасности сводится к доказательству того, что модель исследуемой программы М принадлежит отношению E(M,v), где v принадлежит множеству V.

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

На основании полученных результатов можно сделать заключение о степени безопасности программы. Ключевыми понятиями здесь являются «способ представления» и «модель программы». Дело в том, что на компьютерную программу можно смотреть с очень многих точек зрения - это Испытуемая программа Средства Составление сценария испытаний контроля и протоколирова ния Средства Осуществление контрольного запуска, анализа получение значений контролируемых протоколов параметров P запуска Требования к Заключение об уровне безопасности безопасности программы - проверка истинности (множество С) предикатов C Рис.7.2. Схема анализа безопасности ПО с помощью контрольно испытательных методов Исследуемая программа Выбор системы моделирования Задание отношения эквивалентности Средства Построение модели программы M анализа и преобразования программ Построение модели или порождение РПС моделей РПС (V) Средства преобразовани Разрешение вопроса об эквивалентности я моделей и модели программы моделям РПС E(M,V) определения отношений между ними Рис. 7.3. Схема анализа безопасности ПО с помощью логико-аналитических методов и алгоритм, который она реализует, и последовательность команд процессора, и файл, содержащий последовательность байтов и т.д. Все эти понятия образуют иерархию моделей компьютерных программ. Можно выбрать модель любого уровня модели и способ ее представления, необходимо только чтобы модель РПС и программы были заданы одним и тем же способом, с использованием понятий одного уровня. Другой серьезной проблемой является создание формальных моделей программ, или хотя бы определенных классов РПС. Механизм задания отношения между программой и РПС определяется способом представления модели.

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

В целом полный процесс анализа ПО включает в себя три вида анализа:

• лексический верификационный анализ;

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

• семантический анализ программ.

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

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

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

• сигнатуры вирусов;

• сигнатуры элементов РПС;

• сигнатуры «подозрительных функций»;

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

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

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

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

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

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

7.4. СРАВНЕНИЕ ЛОГИКО-АНАЛИТИЧЕСКИХ И КОНТРОЛЬНО ИСПЫТАТЕЛЬНЫХ МЕТОДОВ АНАЛИЗА БЕЗОПАСНОСТИ ПРОГРАММ Для сравнения методов предлагаются следующие признаки:

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

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

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

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

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

Разделение методов, их особенности и преимущества показаны в табл.7.1.

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

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

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

Таблица 7. Методы Контрольно- Логико-аналитические испытательные Способ Пространство отношений Пространство представления программы с программ.

предметной объектами КС.

области Принцип поиска Фиксация установления Доказательство РПС программой нелегитимности принадлежности отношения доступа к программы к множеству объектам КС. РПС.

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

Решение проблемы Статистические и Не требуется.

перечислимости экстраполяционные методы рабочего теории верификации и Методы Контрольно- Логико-аналитические испытательные пространства функционального тестирования.

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

Ошибки второго Маловероятны. Чем строже Неизбежны. Определяются рода требования по безопасности, мощностью выбранного тем меньше вероятность разрешимого подмножества ошибки. РПС.

Преимущества Не требует теоретической Опирается на формальные подготовки. методы.

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

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

конкретных КС. Инвариантность метода по отношению к различным классам программ.

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

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

ресурсов. Процесс тестирования требует выделения испытательной КС и должен проводится специалистами.

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

2. Создать методы анализа безопасности ПО, используя выбранные формальные определения, доказать их эффективность и реализуемость;

3. Создать конкретные программные средства, реализующие методы анализа безопасности программ в конкретных аппаратно программных средах;

4. Создать методики применения этих средств и оценить их эффективность.

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

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

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

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

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

Задача первого этапа решается известными методами дизассемблирования.

Все средства исследования ПО можно разбить на 2 класса:

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

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

Помимо этих двух основных инструментов исследования, можно использовать:

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

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

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

главу 12).

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

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

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

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

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

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

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

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

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

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

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

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

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

измерение характеристик, сбор и обработку данных по результатам экспериментов (проведения испытаний, тестирования и т.д.);

выбор метода (методов) оценивания;

расчет оценок значений показателей качества;

принятия решения о качестве ПО.

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

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

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

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

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

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

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

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

Состав методического обеспечения проведения испытаний программ Методическое обеспечение проведения испытаний программных средств включает базовые и частные методики.

А. Базовые методики.

А.1. Методики испытаний:

• методика моделирования программ;

• методика модельных испытаний;

• методика испытаний по требованиям качества;

• методика испытаний по требованиям безопасности.

А.2. Методика оценки показателей качества (ПК):

• методика выбора номенклатуры ПК;

• методика автоматизированной оценки ПК;

• методика экспертной оценки ПК.

А.3. Методики экспертизы ПО:

• методика экспертизы качества ПО;

• методика экспертизы безопасности ПО.

А.4. Методики оценки требований к ПО:

• методика экспертизы требований.

А.5. Методики принятия решений:

• методика расчета относительных оценок ПК;

• методика принятия решения о качестве ПО;

• методика принятия решения о безопасности ПО;

• методика принятия решения о выдаче сертификата качества;

• методика расчета страховых рисков.

Б. Частные методики.

Б.1. По показателям качества:

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

Б.2. По видам ПО:

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

Состав инструментальных средств проведения испытания программ В состав инструментальных средств проведения испытания программного обеспечения могут входить:

• анализаторы исходных текстов программ;

• анализатор объектных кодов программ;

• программы модельных испытаний;

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

• программы оценки показателей безопасности ПО;

• программы экспертизы выполнения требований;

• программы интерфейса эксперта;

• программы принятия решений;

• программы расчета рисков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• определение нормативно-технических документов, устанавливающих систему показателей качества ПО;

• формирование из установленной системы показателей номенклатуры показателей качества оцениваемого ПО по i-ому уровню иерархии и установление логических связей между показателями;

• определение каждого выбранного показателя качества ПО i-го уровня;

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

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

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

2). Множество Q1 показателя качества верхнего уровня должно совпадать или быть вложенным в объединение множеств Q1 подчиненных показателей всех нижних уровней.

3). Множество Q2 показателей верхнего уровня должно соответствовать цели оценки качества ПО.

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

5). Между элементами множества Q2 показателей одного уровня должно существовать взаимнооднозначное соответствие.

6). Множество Q3 показателя i-го уровня должно совпадать с объединением множеств Q3 подчиненных показателей i-го уровня.

7). Для множеств Q4 справедливо правило 1.

Расширение и уточнение этих правил устанавливается в методиках (методических материалах) по оценке качества конкретных ПО.

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

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. Рациональный синтез информации, полученной на первых трех этапах и выработка решения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Техническое обоснование, системный анализ, проектирование и стратегическое планирование работ по созданию комплекса программ с учетом характеристик всех структур КС на основе систем имитационного моделирования и САSЕ-средств.

2. Разработка компонентов (получение программного кода) программных комплексов на основе инструментальных средств разработки.

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

4. Проведение стендовых и приемо-сдаточных комплексных испытаний разработанных программных изделий на основе тестирования в соответствии с программой и методикой испытаний.

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

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

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

1. Средства экспертизы и организации тестирования ПО.

2. Средства проведения тестирования.

3. Средства ликвидации дефектов.

4. Средства обеспечения тестирования.

Средства экспертизы и организации тестирования ПО состоят из следующих компонентов:

• экспертного анализатора контроля безопасности;

• блока прогнозирования участков воздействия дефектов;

• моделей угроз безопасности ПО;

• планировщика тестов контроля технологической безопасности.

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

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

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

Экспертный анализатор Блок прогнозирования объектов контроля местоположений безопасности ПО воздействия программных дефектов Модели угроз безопасности ПО Планировщик тестов на безопасность Средства обнаружения дефектов в ПО Подсистема генерации тестов Блок Блок Блок средств автодиагн контроля контроля остики инструмента вычислительных ПО льных программ и База данных средств динамического тестирования б ПО Рис.7.4 Структурно-функциональная схема инструментального комплекса поддержки создания безопасного ПО.

0 1 2 Средства локализации дефектов ПО Блок идентификации Блок определения Блок сбора статистики дефектов ПО характеристик ПО о дефектах и их каталогизация Средства ликвидации дефектов ПО Блок ликвидации Блок удаления нарушенных Блок уделенных модулей формирования информационных структур и искаженных программ и дефектов восстановления их целостности избыточных модулей Генератор отчетов Блок оценки уровня безопасности ПО контроля безопасности ПО Продолжение рисунка 7. Средства проведения тестирования состоят из следующих элементов:

• средств обнаружения дефектов в ПО;

• средств локализации дефектов;

• системы генерации тестов;

• базы данных тестирования.

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

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

В интересах контроля безопасности ОСПО осуществляется:

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

В целях контроля безопасности СПО выполняется:

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

Для контроля безопасности инструментальных средств разработки программ предусмотрено:

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

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

• одноразовость и многоразовость (саморепродуцирование) применения;

• самоликвидируемость;

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

• изменяемость (неизменяемость) объема программ;

• модифицируемость информационных структур;

• самомодифицируемость.

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

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

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

• блок ликвидации модулей формирования дефектов;

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

• блок удаления нарушенных информационных структур и восстановления их целостности.

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

Средства обеспечения тестирования состоят из следующих компонентов:

• блока сбора статистики о дефектах и их каталогизации;

• блока оценки уровня безопасности ПО;

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

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

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

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

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

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

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

Технологическая проверка программных средств организуется, как правило, в среде локальной вычислительной сети (ЛВС), в рамках которой имитируются реальные условия их применения и одновременно реализуется тестовый контроль посредством объединения отдельных подсистем через протоколы высокого уровня.

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

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

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

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

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

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

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

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

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

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

• обеспечивать диспетчеризацию, управление и администрирование информационно-вычислительным процессом в сети ПЭВМ;

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

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

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY Поэтому необходимо создание конструктивно новых испытательных стендов, представляющий собой программно-аппаратные комплексы, наполненные моделями внешней и внутренней сред функционирования программ, их реальными макетами, средствами выявления разрушающих воздействий на ПО и контроля целостности информации. В основе создания испытательного стенда можно предложить для реализации технологию распределенной обработки информации «клиент-сервер» и принять следующие принципы его построения.

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

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

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

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

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

6. Защищенность, под которой понимается изолированность штатных программно-аппаратной среды стенда от деструктивных воздействий со стороны испытываемых программ.

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

• сектора макетов комплексов программ КС;

• автоматизированного рабочего места (АРМ) обнаружения и ликвидации дефектов;

• АРМ экспертного тестирования;

• сектора имитации моделей информационных угроз;

• сектора планирования и анализа результатов тестового контроля;

• сектора проектного анализа объектов контроля безопасности;

• сервера эталонов КП;

• сервера тестов;

• АРМ администратора стенда.

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

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

АРМ экспертного тестирования предназначено для статического тестирования вероятностных характеристик наличия закладок в программах и оценки показателей их качества независимыми экспертами по специальным методикам и в соответствии с ГОСТ 28195-89.

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

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

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

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

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

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

АРМ администратора стенда реализует следующие общесистемные функции:

• многоуровневая защита и изоляция элементов сети стенда и циркулирующей в нем информации от несанкционированного доступа как от абонентов сети, так и тестируемого ПО;

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

• конфигурирование и реконфигурирование архитектуры стенда;

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

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

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

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

• высокое быстродействие, качество и значительный объем средств тестирования и разработки ПО;

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

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

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

• экспериментально проверенная согласованность по протоколам обмена с другими распространенными ОС;

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

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

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

Сущность вероятностного тестирования заключается в следующем.

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

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

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

Требуется определить.

• последовательность законов распределения F1(x),...,Fn(x), j=1,..., входных величин Х={xj}, при которой с вероятностью Рпр гарантируется отсутствие в тестируемой программе РПС;

при этом с вероятностью Р0 такие дефекты могут иметь место в нетестированных участках программы;

• множество контрольных точек (КТi), i=1,...,k, в которых определяется экспериментальное распределение выходных величин;

• множество Gi вероятностных характеристик, снимаемых с заданного множества КТ;

• множество величин Li таких, что если существует i, что (Giэкс-Giэт>Li), то программа содержит дефекты с вероятностью Р0 или не содержит их с вероятностью Рпр.

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

определить множество информативных характеристик Gi случайных величин, снимаемых с некоторого множества КТi исследуемой программы;

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

7.6.2. Обоснование состава множества информативных характеристик Выбор информативных ВХ случайных величин Gi должен производиться с учетом двух основных факторов:

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

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

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

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

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY Для вычислительных программ, обладающих достаточно простой ациклической структурой, но реализующих сложные вычислительные функции, например, вычисления полиномов различной степени в приближенных расчетах, в качестве вероятностных характеристик могут использоваться начальные моменты законов распределения входных данных n * mk = )k (yi n i= где yi - значения входной величины при i-том испытании (прогоне программы);

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

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

7.6.3. Алгоритмы приближенных вычислений вероятностных характеристик наличия в программах РПС В основу алгоритмов приближенных вычислений ВХ положен принцип расчета ВХ по функциям распределения выходных и промежуточных величин. При этом законы их распределения вычисляются как распределения функции от случайных аргументов [ЕУ].

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

Дано: совместная плотность распределения вероятностей wn(x1,...,xn) непрерывных случайных величин 1,...,n и совокупность функций f1,...,fm от n переменных. С помощью этих функций определены m случайных величин h1=f1(x1,...,xn),...,hm=fm(x1,...,xn), где xi – значения случайных величин i.

Необходимо: определить закон распределения каждой полученной случайной величины hj и их совместную плотность Wm(y1,...,ym), где yi - значения случайных величин hj.

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

Вычисление W(y) методом характеристической функции [КК] ограничено таким набором w(x) и f(x), для которых можно вычислить характеристическую функцию в явном виде, а по характеристической функции вычислить W(y).

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

mk(h)=... f(x1,...,xn)kw(x1,...,xn) dx1...dxn - или для одномерного случая h=f(x) mk(h)= f(x)kw(x) dx при условии, что этот интеграл сходится абсолютно [КК].

Поскольку данный методический подход возможен практически для любых вычислительных алгоритмов, то для иллюстрации его реализуемости можно ограничиться классом функций, представимых N a xi конечным степенным рядом. В этом случае если f(x)= i (общий вид), i= то определение первых t=r/N моментов случайных величин h=f(k) выполняется по следующему алгоритму (r – число первых начальных моментов закона распределения w(x), принимающих значения m1(),...,mr()).

Алгоритм A А1. i:=1.

А2. Вычислить значения bj, j=1,...,N полинома f(x)i путем N (i-1) N p xl z x перемножения f(x)i и f(x)i-1: если f(x)= al и f(x)i-1= p, l=0 p= N (i-1) a z то bj= q j-q.

q= Ni b mj () А3. Вычислить mi(h)= j.

j= А4. i:=i+1.

А5. Если ir/N, то переход на п.А2. В противном случае алгоритм завершается.

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

Задача вычисления закона распределения F(y) в заданной точке y0 по L моментам формулируется следующим образом.

Дано: mi, i=1,...,L - начальные моменты F(y).

Необходимо: определить значения sup F(y0) и inf F(y0).

Метод вычисления sup F(y0) и inf F(y0) по известным начальным моментам F(y) описан в [Че]. Алгоритм вычисления sup F(y0) и inf F(y0) для L=2k-1, k=1,2..., и известных а и b – конечных значений y, меньше и больше которых соответственно значения функции принимать не могут, реализуют данный метод с некоторыми модификациями.

Алгоритм Б Б1. Сформировать ряд «подходящих» дробей к интегралу b m1 mL dF (x) = + +... + 2 L+ z - y z z z a Б2. Преобразовать «подходящую дробь» в непрерывную вида.

1z + 1 2 z + 2...........

z + L-1 L- Б3. Привести непрерывную дробь к дробно рациональному виду L(z)/L(z).

Б4. Выполнить пункты Б2 и Б3 для L=L-1 и вычислить L-1(z)/L-1(z).

(z)z - (z) 0 (z) L L- A(z) = = Б5. Определить функцию.

(z)z - (z) 1(z) L L- Б6.Определить вещественные корни полинома 1(z).

y dF ( y) Б7. Вычисление интеграла с помощью вычетов.

a При этом inf F(y0) будет равно сумме вычетов 0(z)/1(z) для всех y,y0, а sup F(y0), будет равно сумме inf F(y0) и очередного вычета.

Среднее значение Fср(y0)=(sup F(y0)+inf F(y0))/2 и значение =(sup F(y0)+inf F(y0))/2, определяющее точность восстановления функции распределения, зависят от mi, i=1,...,L и y0. Однако 1/L+1.

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

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

Дано:

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

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

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

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

Дано: Р=F(y0);

q=1-P=P(y>y0);

задано число прогонов программы n и значения доверительной вероятности Р0.

Необходимо: определить значение доверительного интервала L частоты появления события {A-yj

Для независимых испытаний частота появления события А-yi

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

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

Аналогичным образом доверительный интервал может быть определен и для случая, когда в качестве информативной характеристики программы используется математическое ожидание выходной случайной n * m1 (y0 ) = y величины: j.

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

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

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

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

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

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

w(x) dx- w(x) dx, i j i j где i - интервалы аргумента, где f1(x)

j - интервалы аргумента, где f2(x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Количественная оценка сложности программы при помощи управляющего графа вычисляется [Лип0] как сумма V=e-n+2p, где e – число дуг, n - число вершин, p - число связных компонент графа. Оценкой сложности можно пользоваться и при проектировании программ: если сложность превосходит некоторое критическое значение, то программу целесообразно разбить на более мелкие модули для упрощения ее понимания и отладки. В качестве критической сложности обычно принимают значение 10 единиц.

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

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

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

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

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

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |



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

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