4. Системы аутентификации электронных данных

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

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

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

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

5. Средства управления криптографическими ключами

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

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

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

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

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

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

используя один или несколько центров распределения ключей.

Вопрос10. Процесс разработки по

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

Действия в процессе разработки программного обеспечения

Анализ требований к продукту

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

Анализ области работы часто является первой ступенью лестницы проектирования нового фрагмента программного обеспечения, вне зависимости от того, является ли он добавлением к уже существующему приложению или новым приложением, подсистемой или совершенно новой системой. Принимая, что разработчики (так же как и аналитик) не являются в начале достаточно образованными в области знаний нового программного обеспечения, первая задача — это собственно исследование этой самой области знаний. Чем лучше разработчики знают область, в которой работают, тем меньше потом возникает работы. Также её проводят для того, чтобы позже не появлялось путаницы в терминологии, и пониманием того, что делает эта программа. Если аналитик использует неверную терминологию, то опять же возможны недопонимания, в результате того, что программа будет делать не то, что нужно. Эта работа исключает случаи вроде «Я знаю, что вы верите в то, что поняли, что я говорю, но я не уверен, что вы понимаете, что то, что вы слышали — это не то, что я имею в виду.»

Спецификация

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

Архитектура

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

Проектирование, реализация и тестирование

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

Распространение и поддержка

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

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

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

Модели

Водопад

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

Спецификация требований

Проектирование

Кодирование

Интеграция

Тестирование и отладка (валидация и верификация)

Установка

Поддержка

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

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

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

Гибкая модель разработки

Гибкая модель разработки создана организациями, занимающимися итерационной разработкой. Для этого используется более гибкий, централизованный на людях подход, чем использующийся в традиционных подходах. Гибкие процессы используют обратную связь вместо планирования как главный контролирующий механизм. Обратная связь ведётся посредством регулярных тестов, а также частых релизах разрабатываемого продукта. Интересно, что исследования показывают потенциал для хорошего улучшения производительности относительно стандартного «водопадного» метода. К примеру исследование, опубликованное в августе 2006 года, и базированное на опросах более чем 700 компаний, гласит о огромной прибыли при использовании этой модели. Исследование было повторено в августе 2007 года с базой в 1,700 компаний

Итерационные подходы

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