Особенности исследования защищенного ПО

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

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

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

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

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

Однако не все РПС, особенно

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

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

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

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

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

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

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

Один из возможных подходов к созданию модели угроз технологической безопасности ПО КС может основываться на обобщенной концепции технологической безопасности компьютерной инфосферы[Е1,ЕП, ЮП1,ЮП2], которая определяет методологический базис, направленный на решение, в том числе, следующих основных задач:

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

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

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

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

Модель угроз должна включать:

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

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

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

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

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

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

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

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

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

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

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

Модель угроз должна включать:

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

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

Получестная модель

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

может быть как функция полинома).

Рассмотрим схему с вычислениями над GF(2) для оценки значения

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

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

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

Более точно, нас интересует конфиденциальное вычисление следующих рандомизированной вычислимой m-арной функции

((a1,b1),...,(am,bm))®(c1,...,cm)ÎR*{0,1}m, (3.3)

. (3.4)

Таким образом, необходимо конфиденциально вычислить посредством m-стороннего протокола вышеупомянутую вычислимую функцию. Это делается посредством конфиденциального сведения (для независимого m) вычисления уравнений (3.3)-(3.4) к вычислению тех же самых функциональных зависимостей для случая m=2, которые, в свою очередь, соответствуют уравнениям (3.1)-(3.2).

Получестные модели

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

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

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

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

Постановка задачи

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

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

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

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

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

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

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

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

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

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

·          множество Gi

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

·          множество величин Li

таких, что если существует i, что

(½Giэкс-Giэт½>Li), то программа содержит дефекты с вероятностью Р0

или не содержит их с вероятностью Рпр.

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

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

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

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

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

Алгоритм Б

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

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

Б3. Если все входы рассмотрены, то выполняется переход к шагу Б9, иначе выполняется переход к шагу Б4.

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

Б5. Если текущая вершина пути не выходная, то необходимо перейти к шагу Б6, в противном случае - к шагу Б4 (путь построен).

Б6. Если у последней вершины пути выходят необработанные дуги, то выполняется переход к шагу Б7, в противном случае - к шагу Б8.

Б7. В текущий путь включается необработанная дуга с началом в последней (текущей) вершине пути. Если таких дуг несколько, то выполняется переход к шагу Б5.

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

Б9. Участкам пути, входящим в макровершины, присваиваются весовые коэффициенты в соответствии с весами макровершин. Для каждого полного пути определяется весовой коэффициент пути, равный сумме весов входящих в него участков.

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

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

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

·          при выполнении шага Б8 ограничения на допустимое множество накладываются в соответствии с двумя соображениями: во-первых, желательно получить не слишком длинные пути, так как весьма вероятно, что они окажутся нереализуемыми, а во-вторых, желательно получить как можно больше путей, однако при этом необходимо контролировать выполнение условия, чтобы число путей не превысило топологическую сложность рассматриваемого участка программы (топологическая сложность определяется при построении структурного дерева программы по алгоритму Б);

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

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

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

Построение самотестирующейся/самокорректирующейся

Сначала рассмотрим следующие 4 алгоритма (см. рис.4.2 - 4.5). Для доказательства полноты и безопасности указанной самотестирующейся/ самокорректирующейся программной пары доказывается следующая теорема.

Теорема 4.1. Пара программ S_K_exp(x,M,q,g,b) и S_T_exp(x,M,q,g,b) является (1/288,1/8,1/8)-самокорректирующейся/ самотестирующейся программной парой для функции gxmoduloM с входными значениями, выбранными случайно и равновероятно из множества In.

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

Лемма4.1. Программа S_K_exp(M,q,g,b) является (1/8)-самокорректи-рующейся программой для вычисления функции gxmoduloM в отношении равномерного распределения Dn.

Доказательство.

Полнота программы S_K(?) означает, что если оракульная программа P(x), обозначаемая как Exp(?) выполняется корректно, то и самокорректирующаяся программа S_K(?) будет выполняться корректно. В данном случае полнота программы очевидна. Если P(x) корректно вычислима, то из [PM,g(x1)?PM.g(x2)](modM) следует, что fM,g(x)=fM,g(x1)°fM,g(x2)=

gx(mod M)ºRk.

Program S_K_exp(x,M,q,g, Rk); {вход n,x,M,q,g, выход Rk}

begin

for l=1 to 12ln(1/b)

begin

x1:=random(q); {random- функция случайного равновероятного выбора из целочисленного отрезка

[1,...,q-1]}

x2:=(x-x1)modq;

Exp(g,x1,M,R1); {Exp- процедура вычисления gxmoduloM=R}

Exp(g,x2,M,R2);

R0:=(R1×R2)modM;

end;

Rk=choice(R0(l)); {choice- функция выбора из массива, состоящего из 12ln(1/b) элементов, ответов, который повторяется наибольшее количество раз}

end.

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

Program S_T_exp(x,M,q,g,b); {вход x,M,q,g, выход значение предиката output}

begin

t1:=0;t2:=0;

for l=1 to é576ln(4/b)ù

begin

L_T(g,M,q,Rl); {L_T - процедура, реализующая тест линейной состоятельности, выход - Rl}

t1:=t1+Rl;

end;

if t1/é576ln(4/b)ù>1/72 then output:=«false»;

for l=1 to é32(4/b)ù

begin

N_T(g,M,q,Re); {N-T - процедура, реализующая тест единичной состоятельности, выход - Re}

t2:=t2+R;

end;

if t2/é32ln(4/b)ù>1/4 then output:= «false»

else output:=«true»

end.

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

Program L_T(n,R); {вход g,M,q, выход Rl}

begin

x1:=random(q);

x2:=random(q);

x:=(x1+x2)modq;

Exp(g,x1,M,R1);

Exp(g,x2,M,R2);

Exp(g,x,M,R);

if R1×R2=R then Rl:=1

else Rl:=0;

end.

Рис. 4.4. Псевдокод алгоритма теста линейной состоятельности L_T

Program N_T(n,R); {вход g,M,q, выход Re}

begin

x1:=random(q);

x2:=(x1+1)modq;

Exp(g,x1,M,R1);

Exp(g,x2,M,R2);

if R1×g=R2 then Re:=1

else Re:=0;

end.

Рис. 4.5. Псевдокод алгоритма теста единичной состоятельности N_T

Для доказательства безопасности сначала необходимо отметить, что так как x1ÎRZq, то и x2 имеет равномерное распределение вероятностей над Zq. Так как вероятность ошибки e£1/8, то в одном цикле вероятность Prob[Rk=fM,g(x)]³3/4. Чтобы вероятность корректного ответа была не менее чем 1-b, исходя из оценки Чернова [Be1,BLR], необходимо выполнить не менее 12ln(1/b) циклов n.

Лемма 4.2. Программа S_T_exp(n,M,q,g,b) является (1/288,1/8)-самотестирующейся программой, которая контролирует результат вычисления значения функции gxmoduloM с любым модулем M.

Доказательство.

Полнота программы S_T(?) доказывается аналогично доказательству полноты в лемме 4.1, где x1,x2ÎRZq. Полнота теста единичной состоятельности вытекает исходя из следующего очевидного факта. Корректное выполнение теста [PM,g(x1)?PM.g(1)](mod M) соответствует вычислению функции:

fM,g(x)=fM,g(x1)°fM,g(1)=

ºgx(modM)ºRe.

Для доказательства условия самотестируемости необходимо отметить, что так как и в лемме 4.1 для того, чтобы вероятность корректных ответов Rl и Re в обоих тестах была не более 1-b

достаточно выполнить тест линейной состоятельности é576ln(4/b)ù раз и тест единичной состоятельности é32ln(4/b)ù раз.

Можно показать, основываясь на теоретико-групповых рассуждениях, что возможно обобщение программы S_T(?) и для других групп (вышеописанные алгоритмы основываются на вычислениях в мультипликативной группе вычетов над конечным полем). То есть для всех yÎG, P(y)ÎG*, где G*

-представляет собой любую группу, кроме групп G**. К группам последнего вида относятся бесконечные группы, не имеющие конечных подгрупп за исключением {О¢}, где О¢ - тождество группы. Таким образом, можно показать (если параметры выбираются независимо, равновероятно и случайным образом), что программа вида S_T(?) является (e/36,e)-самотестирующейся программой. Из всего сказанного, следует доказательство утверждения леммы n.

Исходя из определения самотестирующейся/ самокорректирующейся программной пары и основываясь на результатах доказательств лемм 1 и 2, очевидным образом следует доказательство теоремы 1 n.

Замечания. Как видно из псевдокода алгоритма Axmodulo N в нем используется операция ABmodulo N. Используя ту же технику доказательств, как и для функции дискретного возведения в степень, можно построить (1/576,1/36,1/36)-самокорректирующуюся/ самотестирующуюся программную пару для вычисления функции модулярного умножения. Это справедливо, исходя из следующих соображений. Вычисление функции fM(ab)=fM((a1+a2)(b1+b2)) следует из корректного выполнения программы с 4-х кратным вызовом оракульной программы P(a,b), то есть:

[PM(a1,b1)+PM(a1,b2)+PM(a2,b1)+PM(a2,b2)](mod M).

Алгоритм вычисления Axmodulo N

выполняется для c=2. Однако, декомпозиция x, как следует из свойства самосводимости функции Axmodulo N, может осуществляться на большее число слагаемых. Хотя это приведет к гораздо большему количеству вызовов оракульной программы, но в то же время позволит значительно снизить вероятность ошибки.

Повторные выполнения RAM-машины

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

Для каждого kÎN, повторные выполнения RAMk-машины на входной последовательности y1,y2,... рассматриваются как последовательность вычислений RAMk-машины, при котором первое вычисление началось с входа y1, когда рабочие ленты и СРUk, и MEMk пусты и i-тое вычисление начинается с входа уi, когда рабочая лента каждой машины (т.е., и СРUk, и MEMk) содержит ту же самую строку, которую она содержала по окончании i-1 вычисления.

Практические вопросы построения обфускаторов

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

private void CalcPayroll(SpecialList employeeGroup)

{

while(employeeGroup.HasMore())

{

employee = employeeGroup.GetNext(true);

employee.UpdateSalary(); DistributeCheck(employee);

}

Рис. 12.1. Псевдокод программы до обфускации

private void _1(_1 _2)

{

while(_2._1())

{

_1 = _2._1(true);

_1._1();

_1(_1);

}

Рис. 12.2. Псевдокод программы после обфускации

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

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

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

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

Правило цикла с условием продолжения без инициализации

Правило вывода W1 - «Цикл с условием продолжения без инициализации»

{I and B} OP

{I}

then

{I} while В do S endwhile (I and not B} <

Если условие I

истинно непосредственно перед началом выполнения цикла с условием продолжения, то и I, и В будут истинными до первого выполнения тела цикла OP. Поскольку (I and В) является предусловием для I по отношению к OP, то I

будет истинным после первого выполнения OP. Поэтому и I, и В

будут истинными до второго выполнения тела цикла OP и так далее. Условие I будет истинным после каждого выполнения OP. Если когда-то наступит такой момент, что выполнение цикла закончится, то условие I будет истинным, а условие В ложным. То есть условие (I and not В) будет истинным при завершении цикла (если завершится его выполнение).

Значение условия I

истинное, то есть константа, до и после каждого выполнения тела цикла OP. Поэтому условие I

называют инвариантом цикла. Инвариант цикла является ключевым понятием в разработке и понимании существа цикла.

При применении правила вывода W1

требуется, чтобы инвариант цикла I был истинным до выполнения цикла. Обычно инвариант I

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

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

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

Весьма часто желательно доказать корректность цикла совместно с его инициализацией. Для этого мы располагаем правилом вывода W2.

Правило цикла с условием продолжения с инициализацией

Правило вывода W2 – «Цикл с условием продолжения с инициализацией

Пусть задано условие I

(инвариант цикла).

{V} инициализация {I} and

{I and B} OP

{I} and

(I and not B} Þ Р

then

{V} (инициализация; while В do OP endwhile) {P} <

Правило вывода W2 объединяет в себе (и следует из) правила вывода S1, P1 и W1.

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

1. найти инвариант цикла I (если он не был уже указан разработчиком или программистом);

2. доказать, что {V} инициализация {I} (то есть I изначально истинно);

3. доказать, что {I and B} OP {I} (то есть тело цикла обеспечивает сохранение истинности I) и

4. доказать, что (I and not В}Þ

постусловие P

(то есть P

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

5. показать, что цикл завершается, то есть существует верхняя граница числа выполнений оператора OP.

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

цикла while; иногда она является частью инварианта цикла. Такое выражение называют вариантом цикла. Строго говоря, для шага OP

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

Если значения всех переменных, присутствующих

Правило вывода SP1 – «Подпрограмма или сегмент программы»

Если значения всех переменных, присутствующих в условии В, остаются неизменными при выполнении сегмента программы S

(например, подпрограммы, то

{B} S {B} <

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

Если значения всех переменных, присутствующих

Правило вывода SP2 – «Подпрограмма или сегмент программы»

Если значения всех переменных, присутствующих в условии В, остаются неизменными при выполнении подпрограммы или сегмента программы S и

If

{V} S {P}

then

{V and B} S

(Р and B} and

{V or В} S {Р or В} <

Правило вывода SР2 непосредственно следует из правил вывода SP1, DC1 и DС2.

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

Если значения всех переменных, присутствующих

Правило вывода SP3 – «Подпрограмма или сегмент программы»

Если значения всех переменных, присутствующих в условии В, остаются неизменными при выполнении подпрограммы или сегмента программы S и

If

VÞV1 and

{V1} S {Р1} and

P1ÞР

то цикл с условием продолжения инициализации

{V and В} S {Р and B}

and

цикл с условием продолжения без инициализации

{V or В} S {Р or В} <

Правило вывода SР3 является комбинацией правил вывода SР2 и P1.

Та часть постусловия, которая зависит от результата выполнения S (то есть Р в вышеприведенном утверждении), может быть более слабой по сравнению с тем постусловием, которое в действительности устанавливается при выполнении S (то есть P1). Аналогично соответствующая часть предусловия, которая в действительности удовлетворяется до выполнения S (то есть V), может оказаться сильнее того предусловия, которое требуется для удовлетворительной работы S (то есть V1).

Правило получения предусловия оператора присваивания

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

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

Правило вывода А1 – «Получение предусловия оператора присваивания»

(РхЕ} х:=Е{Р} <

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

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

Правило вывода IF2 – «Получение предусловия условного

оператора if»

{V1} OP1 {P} and

{V2} OP2 {Р}

then

((V1 and В) or (V2 and not B)}

if В then OP1 else OP2 endif {P} <

В действительности правило вывода IF2 представляет правило вывода IF1 с V=[(V1 and В) or (V2 and not В)]. Правило вывода IF2 следует из правил вывода IF1 и P1. Применяя правило вывода IF2, можно получить предусловие заданного постусловия Р по отношению к заданному условному оператору. Сначала получаем предусловия для Р по отношению к частям then и else (в выражениях OP1 и OP2), воспользовавшись подходящими правилами вывода для этих операторов. Затем объединяем два предусловия приведенным выше образом.

Правило последовательности операторов

Правило вывода S1 - «Последовательность операторов»

{V} OP1 {P1} and

{P1} OP2 (Р}

then

{V} (OP1;OP2) {Р} <

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

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

Правило проверки предусловия оператора присваивания

Правило вывода А2 – «Проверка предусловия оператора присваивания»

VÞPxЕ

then

{V} x:=E{P} <

Правило вывода А2 представляет собой комбинацию правил вывода A1 и P1. Из правила вывода P1 следует, что V является предусловием для Р по отношению к оператору присваивания, если (V=РxЕ) and {РxЕ} х:=Е{Р}.

Из правила вывода A1 следует, что {РxЕ } х:=Е{Р}. Поэтому достаточно показать, что VÞРxЕ, если желательно проверить, что {V} х:=Е{Р}.

При применении правила вывода А2

неявно используются два правила вывода (A1

и P1). И действительно, правило вывода A1 используется для получения предусловия. Затем проверяется, что из заданного предусловия вытекает полученное предусловие, то есть, что гипотеза правила вывода P1 удовлетворяется.

Правило проверки предусловия условного оператора if

Правило вывода IF1 – «Проверка предусловия условного оператора if»

{V and B} OP1 {P} and

{V and not B} OP2 {Р}

then

{V} if В then OP1 else OP2 endif {P} <

Если условие V

истинно перед выполнением условного оператора if, то и V, и В истинны непосредственно перед выполнением OP1 (если этот оператор выполняется). Поскольку (V and В) является предусловием для Р

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

будет истинным после выполнения OP2. Таким образом, из истинности V

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

очевидным образом на произвольное число

Правило вывода DC1 – «Разделяй и властвуй»

If

{V1} OP {Р1} and

{V2} OP {Р2}

then

{V1 and V2} OP

{P1 and P2} <

Правило вывода DC1 обобщается очевидным образом на произвольное число элементов (P1, P2, РЗ, P4 и т.д.).

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

Правило вывода DC1 относится к элементам, связанным операциями логического умножения and. Аналогичное правило вывода существует и для элементов, связанных операциями логического сложения or.

представляет собой правило вывода

Правило вывода DC2 – «Разделяй и властвуй»

If

{V1} OP {Р1} and

{V2} OP {Р2}

then

{V1 or V2} OP

{P1 or P2} <

Правило вывода DC3 – «Разделяй и властвуй»

If

{V} OP {Р1} and

{V} OP {Р2}

then

{V} OP {P1 and P2} <

Правило вывода DC3

представляет собой правило вывода DC1

при V=V1=V2.

Правило вывода DC4 – «Разделяй и властвуй»

If

{V} OP {Р1} and

{V} OP {Р2}

then

{V} OP {P1 or P2} <

Правило вывода DC4

представляет собой правило вывода DC2

при V=V1=V2.

Правило усиления предусловия и ослабления постусловия

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

Правило вывода Р1 – «Усиление предусловия и ослабление постусловия»

V Þ V1 and

{V1} OP {P1} and

P1 Þ P

then

{V} OP {P} <

Если условие V

истинно перед выполнением оператора OP и если из V следует V1, то V1 истинно перед выполнением оператора OP. Если V1 является предусловием для P1 по отношению к OP, то P1 будет истинным после выполнения оператора OP. Если, наконец, из P1 следует Р, то и Р будет истинным после выполнения оператора OP. Иными словами, из истинности V перед выполнением OP следует истинность Р после его выполнения. Следовательно, V является предусловием для Р по отношению к OP.

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

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

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

В then OP1 else OP2

Правило вывода IFЗ – «Условный оператор if»

If

{V1} OP1 {P} and

{V2} OP2 {Р}

then

{V1 and V2} if В then OP1 else OP2 endif {P} <

Правило вывода IF3

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

V2 and not B} OP2

Правило вывода IF4

–«Условный оператор if»

If

{V1 and B} OP1 {P} and

{ V2 and not B} OP2 {Р}

then

(V1 and V2} if В then OP1 else OP2 endif {Р} <

Правило вывода IF4

также следует из правил вывода IF1

и P1. Подобно правилу вывода IF3

оно обладает определенной практической полезностью вследствие простоты формы предусловия (V1 and V2).

Целью настоящего курса является углубление

« Целью настоящего курса является углубление и развитие трудностей, лежащих в основе современной

теории...»
А.А. Власов
Из кн. «Физики шутят». – М.: Мир, 1993.
Центральным информационно-активным звеном любых компьютерных систем является их математическое, программное, информационное и лингвистическое обеспечение. Современные компьютеры и сети компьютеров, обладающие «потрясающими» вычислительными, информационными и телекоммуникационными возможностями, со своим сложным «внутренним технологическим миром», остаются широким полем деятельности для человека, который создает и совершенствует и сами компьютеры, и те задачи, которые они решают. При этом основным техническим инструментом для этого является программное обеспечение, которое наряду с интеллектом человека, его навыками и знаниями, позволяет создавать сложные и порою удивительные компьютерные объекты, существенно расширяющие горизонты деятельности человека, облегчающие нашу повседневную жизнь и делающие ее активнее и разнообразнее.

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

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

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

Таким образом, необходимость внесения в программное обеспечение защитных функций на всем протяжении его жизненного цикла от этапа уяснения замысла на создание программ и их разработки до этапов испытаний, эксплуатации, модернизации и сопровождения программ, не вызывает сомнений.
В связи с этим, в гл. 1 рассмотрены методологические основы проблемы защиты программ различных объектов автоматизации. Описаны жизненный цикл современных программных комплексов, модели угроз и принципы обеспечения безопасности программного обеспечения.
В главах 2-10 рассмотрены современные методы обеспечения безопасности программ на этапе их разработки и испытаний. Важное место отводится методам создания алгоритмически безопасного программного обеспечения, позволяющим «игнорировать», а в ряде случаев и устранять, программные дефекты деструктивного характера. При этом в главах 2 и 3 рассматриваются методы высокоуровневой защиты программ от так называемых «программных закладок», а в главах 4 и 5 – теоретические основы защиты программ от компьютерных вирусов и от копирования. В главах 6-10 рассматриваются вопросы обеспечения технологической безопасности программ, реализуемые на этапах тестирования и испытания программных комплексов и методы защиты программ от генерации программных закладок инструментальными средствами.
Современные методы обеспечения эксплуатационной безопасности программного обеспечения рассматриваются в главах 11-14. Основное внимание уделено методам обеспечения целостности и достоверности программного кода, защите программ от несанкционированного копирования и распространения.

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

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

автор

Представление чисел

Пусть A, N, e - три целых положительных числа многократной точности, причем A<N. Тогда для любого e при вычислении Ae(modN)ºC, результат редукции CÎ{1,N-1}. Если e представить n-разрядным двоичным вектором, то всю операцию возведения в степень можно свести к чередованию операций вида A*B modulo N и B*B modulo N, где 0<B<N-1 [Кн, стр.482-510]. Таким образом, во всех дальнейших рассуждениях e будет представляться только как двоичная строка. Кроме того, числа A, B, N, а также P - частичное произведение и S - текущий результат будут представляться n-битовыми двоичными векторами, например, N[1,n], где N[1] и N[n] - младший и старший биты N

соответственно.

Алгоритм Р (при разработке и доказательстве его правильности использованы результаты работы [Bk]), реализует вычислительную систему с фиксированной длиной слова, то есть A, B, N, P и S будут также рассматриваться как векторы A[1,m], B[1,m], N[1,m], P[1,m'] и S[1,m'], где каждый элемент вектора (элемент одномерного массива) есть цифра r-ичной системы счисления, m'=m+h, величина h будет изменяться в зависимости от вида алгоритма. Основание r

такой системы будет ограничено длиной машинного слова l и цифры такой системы имеют вид 0,1,...,r-1 (r выбирается как целое положительное основание с неотрицательной базой). При этом n и m

связаны соотношением n=s*m, где s=log2r (в дальнейших рассуждениях log - логарифм по основанию 2). Наиболее целесообразно выбрать основание r=2l как наиболее экономное представление чисел в машине, так как при r<2l на представление чисел уходит больше памяти. Например, широко принятое на практике представление десятичных чисел в двоично-десятичном коде требует на 20 % большего объема памяти, чем двоичное представление тех же чисел.

Тем не менее, иногда полезно представлять ситуацию, когда r=10 [Кн, стр.283] или r=10k, например, при отладке программ.

Следует также обратить внимание на тот факт, что при выполнении арифметических операций над числами многократной точности, например, по классическим алгоритмам Кнута [Кн, стр.282-302], основание r

следует уменьшать, чтобы не возникло переполнение разрядной сетки. Так, для операции сложения уменьшение выполняется до r=2l-1, для умножения - до r=2l/2. Однако если архитектурой вычислительной системы предусмотрен флаг переноса или хранение промежуточного результата с двойной точностью, то можно возвращаться к основанию r=2l.

Предусловия и постусловия в доказательствах правильности

Условие — это алгебраическое выражение, значение которого либо «ложно», либо «истинно». Обычно в выражениях присутствуют имена переменных программы; каждому имени соответствует значение соответствующей переменной. Условия также называют логическими выражениями, булевыми выражениями или суждениями.

Если из истинности условия V непосредственно перед выполнением оператора S следует истинность условия Р после выполнения этого оператора, то говорят, что V

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

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

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

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

Преобразования, защищающие программное обеспечение

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

Далее даются определения компиляторов

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

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

и программы П для RAMk возвращает пару (f,Пf) так, чтобы:

f:{0,1}O(k)®{0,1} – случайно выбранная функция;

½Пf½=O(½П½);

для k'=k+O(log k) существует оракульная RAMk' -машина такая, что для каждой П, каждой f и каждого xÎ{0,1} инициируется RAMk' на входе (Пf,x) и при доступе к оракулу f обеспечивает выход П(x).

Оракульная RAMk' -машина отличается от RAMk-машины в том, что RAMk' имеет доступ к оракулу, в то время как RAMk

нет. Понятно, что RAMk'

имеет большую память, а именно RAMk' -машина состоит из 2k'=poly(k)2k

слов, в то время как память RAMk

состоит из 2k слов.

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

Оракул спецификации для программы П – это оракул, который на запрос x возвращает тройку (П(x),tП(x),sП(x)).

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

Определение 5.6. Для данного компилятора C и противника ADV, компилятор C защищает программное обеспечение от противника ADV, если существует вероятностная оракульная машина М, удовлетворяющая следующим условиям:

(М функционирует примерно за то же самое время, как и ADV) Существует полином p(·) такой, что для каждой строки a время выполнения М на входе (k',½a½) (с учетом доступа к случайному оракулу) было ограничено p(k')T, где T обозначает время выполнения ADV при экспериментировании с RAMk' на входе a;

(М с доступом к оракулу спецификации обеспечивает выход почти идентичный выходу ADV после экспериментирования с результатами работы компилятора)

Для каждой программы П статистическое расстояние между следующими двумя распределениями вероятностей ограничено 2-k'.

Распределение выхода машины ADV при экспериментировании с

на входе Пf, где (f,Пf)¬C(П). Отметим, что

обозначает интерактивную пару (CPUk',MEMk'), где CPUk' имеет доступ к оракулу f. Распределение берется над пространством вероятностей, состоящим из всех возможных выборов функции f и всех возможных результатов выработки случайного бита («подбрасываний монеты») машины ADV с равномерным распределением вероятностей.

Распределение выхода оракульной машины М на входе (k',O(½П½)) и при доступе к оракулу спецификации для П. Распределение берется над пространством вероятностей состоящим из всех возможных результатов подбрасываний монеты машины М с равномерным распределением вероятностей.

Компилятор C обеспечивает слабую защиту программ, если C защищает программы против любого невмешивающего противника. Компилятор C

обеспечивает доказуемую защиту программ от вмешательства, если C

защищает программы против любого вмешивающего противника.

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

следующим условием: tП(x)>½П½+½x½ для всех x.

Определение 5.7. Пусть C - компилятор и g:N®N – некоторая целочисленная функция. Затраты компилятора C на большинстве аргументов g, если для каждой П, каждого xÎ{0,1}*

и каждой случайно выбранной f

требуемое время выполнения RAMk'

на входе (Пf,x) и при доступе к оракулу f

ограничены сверху g(T)T, где T=tП(x).

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

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

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

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

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

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

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

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

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

Применение правил вывода

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

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

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

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

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

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

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

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

Применение вычислительных методов к задачам гидролокации

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

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

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

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

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

– случайная величина и случайный вектор в методе наименьших квадратов.

Таблица 4.4.

Примеры применения схемы подписи с верификацией по запросу

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

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

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

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

Примитив «Соглашение об аккумулируемом множестве» (СОАМ-субпротокол)

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

Br-субпротокола и сохранить «этих отправителей сообщений». Однако если более чем n-t завершений Br-субпротокола глобально осуществлены, тогда мы не можем быть уверены в том, что все несбоящие процессоры сохранят то же самое множество. Для этого необходимо всем процессорам выполнить СОАМ-субпротокол, в котором выход несбоящих процессоров этого субпротокола есть общее множество из не менее n-t процессоров, которые завершили Br-субпротокол.

Неформально говоря, выходы процессоров после выполнения

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

Определение3.1. Пусть m, MÎN (в данном контексте m=n-t

и M=n) и пусть U1...UnÍ[M] – коллекция аккумулируемых множеств такая, что процессор Pi

имеет Ui. Будем говорить, что коллекция является (m,t)-однородной, если для каждого планировщика и каждой коалиции из не более чем t

сбоящих процессоров выполняются следующие условия:

· каждый несбоящий процессор Pi будет обязательно иметь êUiê³m;

· каждых два несбоящие процессора Pi и Pj будут обязательно иметь Ui=Uj.

Определение 3.2. Пусть m, MÎN и пусть P - протокол, где вход каждого процессора Pi

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

Условие завершения. Если коллекция U1...Un (m,t)-однородна, тогда с вероятностью 1 все несбоящие процессоры обязательно завершат протокол.

Условие корректности. Все несбоящие процессоры завершат протокол с общим выходом CÍ[M] так, что êCê³m. Кроме того, каждый несбоящий процессор имеет CÍ

, где

значение Ui при завершении протокола.

Схема «Соглашение об аккумулируемом множестве»

Пусть n³3t+1. Субпротокол СОАМ состоит из 2-х этапов (с параметрами m

и M). На первом этапе каждый процессор сначала ждет пока его динамический вход станет размером m. После чего, он выполняет log2 n итераций. В каждой итерации процессор посылает текущее содержание его динамического входа всем другим процессорам, после чего собирает множества, посланные другими процессорами в текущей итерации. Как только накопятся n-t таких множеств в динамическом входе процессора, он приступает к следующей итерации. Это продолжается до тех пор, пока пересечение динамических входов всех несбоящих процессоров, которые получены во всех log2 n

итерациях станет размером не менее m.

На втором этапе процессоры последовательно запускают M раз BА-субпротокол. На j-том шаге процессоры решают, принадлежит ли элемент jÎ[M] согласованному множеству C. То есть вход каждого процессора на j-том шаге BА-субпротокола будет 1 тогда и только тогда, когда j принадлежит динамическому входу процессора. Элемент j принадлежит множеству C тогда и только тогда, когда общий выход j-того шага BА-субпротокола является 1. Свойства BА-субпротокола гарантируют нам, что множество C

содержит пересечение динамических входов всех процессоров, которые получены при завершении первого этапа, и что каждый элемент jÎC

будет в динамическом входе каждого несбоящего процессора.

Протокол СОАМ

Процессор Pi выполняет следующие шаги по входу m, M и аккумулируемому множеству Ui.

1.   Ожидает пока êUiê³m.

2.   Выполнить в цикле r=ëlog nû

раз

2.1.    Послать (r,Ui) всем другим процессорам;

2.2.    Пусть

={Pj, если (r,Sj) получено от Pj}. Ждет пока SjÍU i для не менее чем n-t процессоров PjÎFir.

3. Выполняет M раз BA-субпротокол BA1...BAM, где вход 1 в j-том выполнении субпротокола, тогда и только тогда, когда jÎUi.

4. Устанавливает Ci={j, если выход BAj равен 1}. Ждет пока CiÍUi.

5. Выдает Ci.

Предложение 3.2. Протокол СОАМ – является min(r,(én/3ù-1))-устойчивым протоколом для сети из n

процессоров, где r – граница устойчивости для используемого протокола соглашений.

Доказательство.

Сначала докажем условие завершения. Предположим, что аккумулируемые множества U1,...,Un определяют (m,t)-однородную коллекцию. Покажем, что каждый несбоящий процессор Pi будет событийно завершать протокол.

Замечание.

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

Шаг 1 будет завершен в любом случае. Индукция по числу итераций показывает, что шаг 2 будет также завершен. В каждой итерации r процессор Pi будет событийно получать сообщение (r,Sj) от каждого несбоящего процессора. Кроме того, для каждого процессора Pj

процессор будет событийно иметь SjÍUi (так как система U1,...,Un является однородной). Шаг 3 будет завершен с вероятностью 1, так как все протоколы византийских соглашений завершаются с вероятностью 1. Чтобы доказать, что шаг 4 будет также завершен, необходимо отметить, что если BA-субпротокол выдает 1, тогда существует несбоящий процессор Pk, который запускает BAj-протокол, где jÎUk

и, таким образом, процессор Pi будет событийно иметь jÎUi.

Доказательство свойства корректности начинается со следующего. Согласование выходов процессоров непосредственно следует из определения византийских соглашений. Шаг 4 протокола гарантирует, что CÍUi* для каждого несбоящего процессора Pi.

В заключение необходимо показать, что ÷C÷³m. Пусть Uir обозначает значение аккумулируемого множества Ui по окончании r-ой итерации на шаге 2 при функционировании процессора Pi. Покажем индукцией по r, что каждое множество D из не более чем 2r несбоящих процессоров, которые завершили итерацию r, удовлетворяет ÷ÇjÎDUjr÷³m. Основание индукции (r=0) следует непосредственно из шага 1 протокола. Для шага индукции рассмотрим множество D из не более чем 2r несбоящих процессоров. Отметим, что для каждых двух процессоров Pj,PkÎD имеем ôFjrÇFkrô³t+1, где n³3t+1 и ôFjrô³n-t для каждого j. Поэтому существует не менее одного несбоящего процессора PlÎ FjrÇFkr. Процессор Pl будем называть арбитром Pj

и Pk. Процессор Pj (в отн. Pk) получает сообщение (r,Sl). Кроме того,

Ulr-1ÍSl. Таким образом, Ulr-1ÍUjr (в отн. Ulr-1ÍUkr).

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

является множеством этих арбитров. Таким образом, получим ÷D¢÷£2r-1. По индукции имеем m£÷ÇjÎD¢Ujr-1÷. Каждый процессор из D имеет арбитр из D¢ и, таким образом,

ÇjÎD¢Ujr-1ÍÇjÎDUjr. Отсюда, m£÷ÇjÎDUjr÷.

Пусть D – множество несбоящих процессоров, которые начинают работу на шаге 3 протокола и пусть C¢=ÇjÎDUjlog n. По индукции получим ÷C¢÷³m.Для каждого jÎC выходы всех несбоящих процессоров в

BAj-субпротоколах являются 1. По этому по определению византийских соглашений выход каждого BAj-субпротокола является 1. Таким образом, C¢ÍC и C³m. <

Примитив «Забывающий обмен»

Пусть k

- фиксированное целое и пусть b1,b2,...,bkÎ{0,1} и iÎ{1,...,k}.

Тогда забывающий обмен OTk1

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

OTk1((b1,b2,...,bk),i)=(l,bi).

Эта вычислимая функция является в явном виде асимметричной и реализуется посредством протокола взаимодействия двух участников (процессоров). Обычно первый процессор, который содержит вход (b1,b2,...,bk), называется отправителем (илиS), а второй процессор, который содержит вход iÎ{1,...,k}, называется получателем (или R).

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

С использованием любой перестановки с секретом {fi}iÎI (см. Приложение), ниже описывается протокол для конфиденциально вычисления OTk1. Так как мы имеем дело с конечными вычислимыми функциями, безопасность будет рассматриваться в терминах некоторого дополнительного параметра n, именуемого далее параметром безопасности.

Протокол ОТПЧМ

Вход:

Отправитель R

имеет вход b1,b2,...,bkÎ{0,1}k, а получатель S имеет вход iÎ{1,...,k} и обе стороны имеют дополнительный параметр безопасности 1n.

1. Отправитель S равномерно выбирает пару односторонних функций с секретом (a,t) (см. Приложение), выполняя алгоритм их генерации G по входу 1n. Параметр a отсылается R.

2. Получатель R равномерно и независимо выбирает e1,...,ekÎR*Da, устанавливает yi=f(ei) и yj=ej для каждого j¹i и отсылает (y1,y2,...,yk) к отправителю S. Для этого:

2.1. Равномерно и независимо выбирает ejÎR*Da каждый раз, вызывая алгоритм генерации ej=D(a,rj), rjÎR*Z, j=1,...,k.

2.2. Вычисляет yi=f(ei).

2.3. Для j¹i присваивает yj=ej.

2.4. Получатель R отсылает (y1,y2,...,yk) к отправителю S. Таким образом, получатель знает fa-1(yi)=ei, однако не может предсказать b(fa-1(yi)) для j¹i.

3. После получения (y1,y2,...,yk), используя знание секрета для инвертирования односторонней функции с секретом, отправитель S вычисляет xj=fa-1(yj) для jÎ{1,...,k}. В свою очередь, S посылает (b1Åb(x1),b2Åb(x2),...,bkÅb(xk)) получателю R.

4. По получении (c1,c2,...,ck) получатель локально выдает ciÅb(ei).

Отметим сначала, что вышеупомянутый протокол корректно вычисляет OTk1 так как

ciÅb(ei)=biÅb(xi))Åb(ei)=biÅb(fa-1(fa(ei)))Åb(ei)=bi.

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

Интуитивно, получатель R не получает никакой (с вычислительной точки зрения) информации при выполнении протокола, так как для j¹i, единственные данные, которые могут «говорить» о bj

– это кортеж (a,ej,bjÅ(fa-1(ej))), из которого невозможно предсказать bj лучше, чем простым угадыванием.

Формальные аргументы даны в работе [Go1].

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

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

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

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

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

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

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

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

Блокирования несанкционированного доступа

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

Статистического учета и ведения системных журналов

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

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

Принципы обеспечения безопасности при эксплуатации программного обеспечения

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

Сохранения эталонов и ограничения доступа

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

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

Идентификации ПО на момент ввода его в эксплуатацию в соответствии с предполагаемыми угрозами безопасности ПО и его контроль.

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

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

Строгого учета и каталогизации

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

Статистического анализа информации

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

Гибкого применения дополнительных средств защиты ПО

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

Принципы обеспечения технологической

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

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

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

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

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

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

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

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

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

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

Проведения натурных испытаний программ

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

Осуществления «фильтрации»

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

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

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

Отработки средств защиты от несанкционированного воздействия нарушителей на ПО.

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

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

Проведения натурных испытаний программ

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

Осуществления «фильтрации»

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

Отработки средств защиты от несанкционированного воздействия нарушителей на ПО.

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

ПРОЕКТИРОВАНИЕ

Проектные решения

Злоумышленный выбор нерациональных алгоритмов работы.

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

Внедрение злоумышленников в коллективы, разрабатывающие наиболее ответственные части ПО.

Используемые информационные технологии

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

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

Внедрение неоптимальных информационных технологий.

Используемые аппаратно-технические средства

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

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

Задачи коллективов разработчиков и их персональный состав

Внедрение злоумышленников в коллективы разработчиков программных и аппаратных средств.

Вербовка сотрудников путем подкупа, шантажа и т.п.

Рис.1.2. Пример типового реестра угроз технологической

безопасности информации и ПО

Протокол византийского соглашения (BA-протокол)

При византийских соглашениях или при реализации протокола византийских соглашений

для любого начального входа xi, iÎ[1,...,n] участника i и некоторого параметраd (соглашения) должны быть выполнены следующие условия.

Условие завершения. Все честные участники вычислений в конце протокола принимают значение d.

Условие корректности. Если существует значение x

такое, что для честных участников xi=x, тогда d=x.

Протокол вычислений на арифметической схеме над GF(

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

между обоими процессорами означает равномерно выбранную пару битов (v1,v2) так, что v=v1+v2, где первый процессор содержит v1, второй - v2. Наша цель заключается в разделении, через частные вычисления, долей входных линий схемы на доли всех линий схемы так, чтобы, в конце концов, мы получили бы доли выходных линий схемы.

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

линиям схемы.

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

Редукция к МВ

Вход.

Процессор i

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

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

процессор i равномерно выбирает бит rij и посылает его другому процессору, как долю входной линии (с нумерацией ((i-1)n+j) последнего. Процессор i устанавливает свою собственную долю на входной линии с нумерацией (i-1)n+j в значение xij+rij.

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

Предположим, что процессоры имеют общие две входные линии вентиля, то есть процессор 1 содержит доли a1,b1, а процессор 2 содержит доли a2,b2, где a1,a2 - доли на первой линии и b1,b2 - доли на второй линии. Рассмотрим два случая.

2.1. Эмуляция аддитивного вентиля. Процессор 1 только устанавливают долю выходной линии вентиля в значение a1+b1, а процессор 2 устанавливают долю выходной линии вентиля в значение a2+b2.

2.2. Эмуляция мультипликативного вентиля. Доли выходной линии вентиля получаются посредством вызова оракула для вычисления функции (см.(3.1)-(3.2)), где процессор 1 обеспечивает вход (часть запроса) (a1,b1), а процессор 2 обеспечивает вход (a2,b2). После ответов оракула, каждый из процессоров устанавливают свою долю выходной линии вентиля в значение равное своей части ответа оракула.

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

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

Выход.

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

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

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

и ее доли - rij и rij+xij.

На каждом шаге индукции рассматривается эмуляция аддитивного или мультипликативного вентиля. Предположим, что значения входных линий – a и b и что их доли a1,a2 и b1,b2, которые удовлетворяют a1+a2=a и b1+b2=b. В случае аддитивного вентиля доли на выходной линии устанавливаются в значения a1+b1 и a2+b2, что удовлетворяет (a1+b1)+(a2+b2)=(a1+a2)+(b1+b2)=a+b. В случае мультипликативного вентиля доли выходной линии были устанавливаются в значения c1

и c2 так, что c1+c2=(a1+a2)·(b1+b2). Таким образом, c1+c2=a·b, что и требовалось показать.

В работе [Go2] приводятся формальные аргументы для конфиденциального сведения вычисления на арифметической схеме над GF(2) к функции, вычислимой в соответствии с уравнениями (3.1)-(3.2). А следующая теорема, устанавливает главный результат для конфиденциального вычисления любой вычислимой функции для случая двухстороннего протокола взаимодействия.

Теорема 3.2.

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

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

Пусть имеется n участников вычислений и t* (значение t* не более порогового значенияt) из них могут отклоняться от предписанных протоколом действий. Один из участников назначается дилером Д, которому (и только ему) становится известен секрет (секретная информация) s. На первом этапе дилер вне зависимости от действий нечестных участников осуществляет привязку к уникальному параметру u. Идентификатор дилера известен всем абонентам системы. На втором этапе осуществляется открытие (восстановление) секрета s

всеми честными участниками системы. И если дилер Д – честный, то s=u.

Проверяемая схема разделения секрета ПРС представляет собой пару многосторонних протоколов (РзПр,ВсПр), - а именно протокола разделения секрета и проверки правильности разделения РзПр

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

Условие полноты. Для любого s, любой константы c>0 и для достаточно больших n вероятность

Prob((n,t,t*)РзПр=(Да,s)¿t*<t & Д

- честный)>1-n-c.

Условие верифицируемости. Для всех возможных эффективных алгоритмов Прот, любой константы c>0 и для достаточно больших n вероятность

Prob((t*,(Да,u))ВсПр=(s=u)¿(n,t,t*)РзПр=(Да,u)&t*<t & Д

- честный)<n-c.

Условие неразличимости. Для секрета s*ÎRS

вероятность

Prob(s*=s¿(n,t,t*)РзПр=(Да,s*) & Д - честный)<1/½S½.

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

завершится корректно с вероятностью близкой к 1. Свойство верифицируемости означает, что все честные абоненты выдают в конце протокола ВсПр значение u, а если Д – честный, тогда все честные абоненты восстановят секрет s=u. Свойство неразличимости говорит о том, что при произвольном выполнении протокола РзПр со случайно выбранным секретом s*, любой алгоритм Прот не может найти s*=s лучше, чем простым угадыванием.

Псевдокод алгоритма

Рис.4.6. Псевдокод алгоритма самотестирующейся

программы для полинома f

Пусть матрицы А и В матрицы размером n´n определены над конечным полем F.

Время выполнения программы, реализующей чекер Фрейвалдса, составляет O(n2élog(1/k)ù).

Используя чекер Фрейвалдса, можно построить самотестирующуюся/ самокорректирующуюся программную пару для умножения матриц (рис.4.8 – 4.9).

Program C_F(A,B,C,k); {вход

A,B,C,k, выход («Норма»,«Сбой»)}

begin

for i=1 to élog(1/k)ù

begin

R:=random(F); {random - функция случайного равновероятного выбора 0-1-вектора размером (n´1) из F};

if C×R¹A×(B×R) then output «Сбой»;

end;

output «Норма»;

end.

Рис.4.7. Псевдокод алгоритма, реализующего чекер Фрейвалдса

Program S_K_multAB(A,B,k); {вход A,B,k, выход С}

begin

for i=1 to ¥ do

begin

A1:=random(F); {random - функция случайного равновероятного выбора матрицы размером (n´n) из F};

B1:=random(F); {random - функция случайного равновероятного выбора матрицы размером (n´n) из F};

A2:=A-A1;

B2:=B-B1;

C:=P(A1,B1)+P(A1,B2)+P(A2,B1)+P(A2,B2);

if C_F(A,B,C,k)=«Норма» then output С

and goto 1;

end;

1:end.

Псевдокод алгоритма самотестирующейся

Рис. 4.9. Псевдокод алгоритма самотестирующейся

программы умножения матриц

Можно легко удостовериться, что, если err(P,f,Un)³1/8, то количество единиц будет не менее 1/16 с вероятностью не менее 1-k и если err(P,f,Un)£1/32, то количество единиц будет не менее 1/16 с вероятностью не менее 1-k. Таким образом, вышеприведенная программа будет (1/32,1/8)-самотестирующейся программой для умножения матриц.

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

Таблица 4.2.

Психология программирования

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

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

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

Внутренняя/внешняя управляемость.

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

Высокая/низкая мотивация.

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

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

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

Корпоративная этика

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

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

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

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

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

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

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

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

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

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

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

RAM-машина как пара интерактивных машин

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

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

Интерактивная машина Тьюринга

– многоленточная машина Тьюринга (см. приложение), имеющая следующие ленты:

входная лента «только-для-чтения»;

· выходная лента «только-для-записи»;

· рабочая лента «для-записи-и-для-чтения»;

· коммуникационная лента «только-для-чтения»;

· коммуникационная лента «только-для-записи».

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

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

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

с коммуникационной лентой «только-для-записи» МП

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

Далее используем k как параметр, определяющий и длину сообщений, и размер рабочих лент ЦП и МП. Кроме того, длина сообщений будет равна k+2+k', а размер рабочей ленты будет равен 2kk', где k'=O(k).

Для каждого kÎN определим MEMk как машину IТМ(k+2+O(k),2kO(k)), работающую точно так, как определено выше. Рабочая лента разбивается на 2k

слов, каждое размером O(k). После копирования входа на рабочую ленту машина MEMk

становится машиной, управляемой сообщениями. После получения сообщения (i,a,v), где iÎ{0,1}2={«запомнить»,«выборка»,«стоп»}, aÎ{0,1}k и vÎ{0,1}O(k), машина MEMk

работает следующим образом.

Если i=«запоминание», тогда машина MEMk копирует значение v из текущего сообщения в число а рабочей ленты.

Если i=«выборка», тогда машина MEMk посылает сообщение, состоящее из текущего содержания слова а

(на рабочей ленте).

Если i=«стоп», тогда машину MEMk копирует префикс рабочей ленты (как специальный символ) на выходную ленту и останавливается.

Далее, пусть для каждого kÎN определим CPUk как машину IТМ(k+2+O(k),O(k)), работающую точно так, как определено выше. После копирования входа на свою рабочую ленту, машина CPUk выполняет вычисления за время, ограниченное poly(k), используя рабочую ленту, и посылает сообщение, полученное в этих вычислениях. В следующих раундах CPUk

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

Число шагов каждого вычисления на рабочей ленте ограничено фиксированным полиномом от k.

Единственная роль входа ЦП заключается в инициализации регистров ЦП, и этот вход в дальнейшем может игнорироваться. «Внутренние» вычисления ЦП в каждом раунде соответствует элементарным операциям над регистрами. Следовательно, число шагов, принимаемых в каждом таком вычислении, является фиксированным полиномом от длины регистра (которая равна O(k)). Теперь можно определить RAM-модель вычислений, как семейство RAMk-машин для каждого k.

Определение 5.1. Для каждого kÎN определим машину RAMk

как пару (CPUk, MEMk), где ленты «только-для-чтения» машины CPUk

совпадают с лентами «только для записи» машины MEMk, а ленты «только-для-записи» машины CPUk

совпадают с лентами «только-для-чтения» машины MEMk. Вход RAMk – это пара (s,y), где s - вход (инициализация) для CPUk и у – вход для MEMk. Выход машины RAMk по входу (s,у), обозначаемый как RAMk(s,у), определен как выход MEMk(y) при взаимодействии с CPUk(s).

Для того, чтобы рассматривать RAM-машину как универсальную машину, необходимо разделить вход у машины MEMk

на «программу» и «данные». То есть, вход у

памяти разделен (специальным символом) на две части, названные программой (обозначенной П) и данными (обозначаемыми x).

Пусть RAMk и s фиксированы и у=(П,х). Определим выход программы П на входных данных х, обозначаемый через П(x) как RAMk(s,у). Определим время выполнения П на данных х, обозначаемое через tП(x), как сумму величины (½у½+½П(x)½) и числа раундов вычисления RAMk(s,у). Определим также размер памяти программы П

для данных х, обозначаемый через sП(x) как сумму величины ½у½

и числа различных адресов, появляющихся в сообщениях, посланных CPUk к MEMk в течение работы RАМk(s,у).

Легко увидеть, что вышеупомянутая формализация непосредственно соответствует модели вычислений с произвольным доступом к памяти.Следовательно, «выполнение П на х» соответствует раундам обмена сообщениями при вычислении RAMk(×,(П,х)). Дополнительный член ½y½+½П(x)½ в tП(x) поясняет время, потраченное при чтении входа и записи выхода, в то время как каждый раунд обмена сообщениями представляет собой единственный цикл в традиционной RAM-модели. Член ½y½ в sП(х) объясняет начальное пространство, взятое по входу.

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

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

Пусть программа P

предположительно вычисляет RSA-функцию и для x,y,zÎZ>0 с x,y<z

и НОД(x,z)=1. Тогда чекер CPRSA(x,y,z;k) работает следующим образом [KA].

Доказательства существования чекера для RSA-криптоалгоритма приведены в работе [KA]. Там же приведены RSA-чекеры для фиксированного модуля криптосистемы.

Program C_RSA_(x,y,z;k); {вход x,y,z,k выход («Норма»,«Сбой»)}

begin

t1:=é-klog99/1002ù;

t2:=é-k/log4/52ù;

for l=1 to t1 do

begin

i:=random(Z); {random - функция случайного равновероятного выбора из [1,...,z[};

if P(x,i,z)º0 (mod z) output «Сбой» and STOP;

i,j:=random(Z); {random - функция случайного равновероятного выбора из [1,...,z[};

if P(x,i,z)P(x,j,z)¹P(x,i+j,z)(mod z) output «Сбой» and STOP;

i:=random(Z); {random - функция случайного равновероятного выбора из [1,...,z[};

if P(x,i,z)ºP(x,1,z)¹P(x,i+1,z)(mod z) output «Сбой» and STOP;

end;

for l=1 to t2 do

begin

r:=random(Z); {random - функция случайного равновероятного выбора из [1,...,z[};

if P(x,y,z)P(x,r,z)¹P(x,y+r,z)(mod z) output «Сбой» and STOP;

end;

output «Норма»;

end.

Рис.4.10. Псевдокод алгоритма RSA-чекера

Разрушающие программные средства

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

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

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

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

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

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

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

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

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

В первом классе воздействий выделим следующие:

·     уменьшение скорости работы вычислительной системы (сети);

·     частичное или полное блокирование работы системы (сети);

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

·     переадресация сообщений;

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

·     обеспечение доступа в систему с непредусмотренных периферийных устройств.

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

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

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

·     идентификацию информации, запрашиваемой пользователями;

·     подмену паролей с целью доступа к информации;

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

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

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

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

·     искажение или уничтожение собственной информации сервера и тем самым нарушение работы сети;

·     модификация пакетов сообщений.

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

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

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

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

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

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

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

Реализация алгоритма «Квадратного корня»

Сначала, мы покажем, как выбирать и сохранять в ЦП

случайную перестановку над {1,2,...,n}, используя O(logn) памяти и случайный оракул. Идея состоит в том, чтобы использовать оракул для проставления меток случайно выбранных элементов и различные целые числа из множества меток, обозначаемого Tn. Перестановка получается посредством сортировки элементов в соответствии с их метками. Если же необходимо получить вероятность коллизии e

(т.е., для нашего приложения e=2-2k), достаточно иметь метки, выбранные случайно из множества Tn={1,2,...,n2/e},. Пусть t : {1,2,...,n}®Tn - случайная функция, тривиально созданная случайным оракулом. В этом случае p(i)=k, тогда и только тогда, когда p(i) - наименьший элемент в {t(j):1£j£n}. В нашем случае n=m+

, а именно n элементов состоят из m виртуальных адресов, связанных с целыми числами 1,...,m

макетов, связанных с (m+1,...,

Теперь мы имеем дело с задачей забывающей сортировки n

элементов посредством меток. Определяющее условие состоит в том, что

RAM-машина, которая выполняет сортировку, может хранить только фиксированное число значений одновременно. Идея состоит в том, чтобы «выполнить» сортирующую сеть Батчера [GO], который позволяет сортировать n элементов, выполняя nélog2nù2 сравнений. Каждое сравнение «выполняется» посредством осуществления доступа к двум соответствующим словам, чтением их содержания и записью этих значений обратно в необходимом порядке. Последовательность операций доступа к памяти, сгенерированной для этой цели фиксирована и не зависит от входа. Отметим, что забывающая RAM-машина может легко вычислять в каждой точке, какое сравнение требуется для реализации следующего. Это следует из простой структуры сети Батчера, которая является однородной относительно логарифмического пространства. Этот алгоритм будет работать, если мы сохраняем метку каждого элемента вместе с самим элементом (виртуальное слово или макет).

Далее мы точно определим, как осуществить доступ к виртуальной ячейке или к макету i. Отметим, что после шага 1 виртуальные ячейки от 1 до m (также как и макеты от m+1 до m+

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

}. Затем, вместо того, чтобы непосредственно достичь фактической ячейки p(i), как предлагается выше, мы выполняем двоичный поиск метки p(i). Этот двоичный поиск заканчивается на фактической ячейке p(i). Помимо этого другие фактические операции доступа, выполняемые во время поиска, полностью определены p(i). Таким образом, эти дополнительные фактические операции доступа не открывают никакой информации противнику.

Далее описываются две альтернативных реализации шага 3. Первый вариант - реверсия модели доступа на шаге 2. Второй вариант – полная сортировка фактической памяти (то есть, все m+2

слов, включая память зщт) дважды, как описано в алгоритме. Первая сортировка выполняется в соответствии с ключом (v,s), где v - виртуальный адрес (¥ - для макетов) и sÎ{0,1} указывает, исходит ли это слово из памяти зщт

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

Далее следует детальное описание шага 2.

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

. Булева переменная found

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

(2a) сканирует полностью память зщт и ищет виртуальный адрес i. А именно, для j, пробегающему значения от m+

+1 до m+2

, доступ к фактической ячейке памяти j переменная found устанавливается в true и сохраняется в ЦП, если виртуальный адрес i

совпадает с фактической ячейкой j. (Переменная found

инициализирована в значение false

до этого сканирования и остается такой же, если виртуальный адрес i не был найден);

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

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

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

+1 до m+2

доступ к фактической ячейке памяти j

запоминается в ее модифицированном значении виртуального адреса i, если адрес j содержит старое значение виртуального адреса i (т.е., found=true), либо found=false и j

- первое пустое слово в памяти зщт.

Значение счт

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

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

RL-прототип модели синхронных конфиденциальных вычислений

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

Рассмотрим многопроцессорную суперЭВМ семейства S-1 на базе сверхбыстродействующих процессоров MARK IIA (MARK V). Такую вычислительную систему назовем RL-прототипом (real-life) модели синхронных конфиденциальных вычислений в реальном сценарии.

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

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

Системы семейства S-1

предоставляют в распоряжение пользователя большую сегментированную память с виртуальной адресацией в несколько миллиардов 9-разрядных байтов. Процессоры соединены между собой с помощью матричного переключателя, который обеспечивает прямую связь каждого процессора с каждым блоком памяти (см. рис.3.1).
При обращениях к той или иной ячейке памяти процессоры всегда получают последнее записанное в ней значение. Команды выполняются в последовательности: «чтение - операция – запись». С целью повышения быстродействия памяти в составе каждого процессора имеются две кэш-памяти: первая – объемом 64 Кбайт для хранения данных, вторая – объемом 16 Кбайт (с перспективой наращивания). В обоих типах кэш-памяти длина набора составляет 4, а длина строки 64 байта.

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

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

Операционная система Amber

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

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

Рис. 3.1. RL-прототип модели синхронных

конфиденциальных вычислений

синхронизации. Параметром безопасности системы может являться длина строки (64-256 Кбайт).

Вычислительная система типа S-1

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

1.     Протоколы византийского соглашения.

2.     Протоколы разделения секрета.

3.     Протоколы электронного голосования.

4.     Протоколы выработки общей случайной строки и многие другие.

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

www.kiev-security.org.ua

BEST rus DOC FOR FULL SECURITY

Секретность в инкрементальных схемах

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

- подпись для электронных данных М

и m'

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

Сертификационные испытания программных средств

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

Сертификация программного обеспечения

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

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

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

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

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

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

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

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

Сертификация программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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