Глава 9. Проблемы реализации. Часть I
что-нибудь пойдет не так. В машине, которая сможет вернуться на землю
и при этом не разбиться, только совершив точную и мастерскую посадку
на один из специально подготовленных участков, которых так немного на
нашей планете. Авиационная индустрия удивительно преуспела в обеспече-
нии безопасности полетов. Было бы хорошо, если бы у нее поучились и все
остальные.
Возможно, написание правильного программного обеспечения
действи-
тельно
ст´оит на порядок дороже, чем на него привыкли тратить сейчас. Тем
не менее, учитывая расходы, которыми оборачиваются ошибки программно-
го обеспечения для современного общества, такое решение показало бы себя
весьма эффективным в долгосрочной перспективе.
9.2
Создание безопасного программного
обеспечения
До сих пор речь шла только о создании правильных программ. К сожале-
нию, одного лишь правильного программного обеспечения недостаточно для
построения системы безопасности. Программное обеспечение должно быть
еще и безопасным.
В чем же различие между правильным и безопасным программным обес-
печением? Правильное программное обеспечение обладает заявленной функ-
циональностью: если вы щелкнете на кнопке
A
, случится событие
Б
. К без-
опасному программному обеспечению выдвигается еще одно требование:
недо-
статочность
функциональности. Что бы ни делал злоумышленник, он не
должен выполнить операцию
X
. Это различие поистине можно назвать фун-
даментальным; можно протестировать программу на предмет функциональ-
ности, но никак не на предмет недостаточности функциональности. Аспекты
безопасности программного обеспечения не могут быть протестированы ка-
ким-либо эффективным образом. Все это делает разработку безопасного про-
граммного обеспечения гораздо более сложной, нежели создание правильного
программного обеспечения. Из этого следует вывод:
Стандартные методы реализации совершенно не подходят
для написания безопасного кода.
В действительности мы не знаем, как создавать безопасный код. Пробле-
ма качества программного обеспечения настолько обширна, что на ее рас-
смотрение понадобилось бы несколько отдельных книг. Мы не разбираемся
в этой теме настолько хорошо, чтобы написать их, но
знаем
наиболее распро-
страненные проблемы реализации, касающиеся криптографии. Именно о них
и пойдет речь в оставшейся части главы.
9.3. Как сохранить секреты
157
Прежде чем переходить к обсуждению этих проблем, давайте проясним
нашу точку зрения: если вы не собираетесь вложить все свои силы в раз-
работку безопасной системы, не стоит и браться за криптографию. Разра-
ботка криптографических систем может быть интересным занятием, однако,
небрежно относясь к их реализации, вы лишь впустую потратите время.
9.3
Как сохранить секреты
Все, кто работает с криптографией, имеют дело с секретами. А секреты
для того и нужны, чтобы сохранять их в тайне. Это значит, что программное
обеспечение, связанное с секретной информацией, должно гарантировать, что
ее утечка невозможна.
Работая с безопасным каналом общения, мы имеем дело с двумя типами
секретов: ключи и данные. И те и другие являются временными; мы не хо-
тим хранить их слишком долго. Данные хранятся только на протяжении того
времени, пока мы обрабатываем каждое сообщение. Ключи хранятся только
на протяжении времени существования безопасного канала общения. В этой
главе обсуждаются только временные секреты. Как обеспечить хранение дол-
госрочных секретов, рассматривается в главе 22, “Хранение секретов”.
Временные секреты хранятся в оперативной памяти компьютера. К со-
жалению, память большинства современных компьютеров не обладает нуж-
ной безопасностью. Ниже описываются типичные проблемы, сопровождаю-
щие хранение секретов.
9.3.1
Уничтожение состояния
Основное правило написания систем безопасности гласит: уничтожайте
всю информацию, как только она вам больше не понадобится. Чем дольше
она будет храниться в памяти компьютера, тем вероятнее, что до нее добе-
рется кто-нибудь посторонний. Более того, не забывайте уничтожать данные
прежде, чем вы потеряете контроль над носителем, используемым для их
хранения. Касательно временных секретов это означает очищение соответ-
ствующих областей памяти.
На первый взгляд кажется, что соблюсти это правило проще простого.
Между тем оно приводит к возникновению огромного числа проблем. Если
вы самостоятельно пишете весь текст программы на языке C, то сможете по-
заботиться об уничтожении данных и сами. Если же вы пишете библиотеку
для использования другими людьми, то попадаете в зависимость от главной
программы, которая должна сообщать вам о том, что то или иное состоя-
ние больше не понадобится. Например, при закрытии соединения криптогра-
фическая библиотека должна получить уведомление о том, что она может
158
Достарыңызбен бөлісу: |