В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 9. Проблемы реализации. Часть I 9.4 Качество кода Реализуя криптографическую систему, необходимо тщательно заботить- ся о качестве кода. В нашей книге речь идет не о программировании. Тем не менее, поскольку большинство учебников по программированию зачастую оставляют качество кода за пределами обсуждения, мы решили посвятить этому вопросу несколько разделов. 9.4.1 Простота Сложность — главный враг безопасности. Каждый разработчик систе- мы безопасности должен стремиться к простоте. Нужно сказать, что в этом отношении мы довольно безжалостны (правда, это не добавляет нам попу- лярности). Уберите из системы все параметры и настройки, какие только возможно. Избавьтесь от всех тех “наворотов”, которые практически никому не нужны. Избегайте разработки структуры системы на заседании комитета, поскольку попытки достигнуть компромисса всегда приводят к появлению в системе дополнительных средств или параметров. В плане безопасности главной должна быть простота. В качестве типичного примера простой системы можно привести наш без- опасный канал общения. У него нет настроек. Он не позволяет зашифровать данные без аутентификации или применить аутентификацию без шифрова- ния. Многие клиенты просят реализовать подобные возможности, но в боль- шинстве случаев они просто не представляют себе последствий частичного использования средств безопасности. Многие пользователи знают о безопас- ности отнюдь не достаточно, чтобы самостоятельно выбирать правильные параметры безопасности. Лучшее, что можно предложить в подобной ситу- ации, — это вообще лишить систему настраиваемых параметров и сделать ее безопасной по умолчанию. Если же без настроек все-таки не обойтись, оставьте один параметр — безопасная или небезопасная. Многие криптографические системы также оснащены несколькими паке- тами шифров. В таких системах пользователь (или кто-нибудь другой) мо- жет самостоятельно выбирать шифр и функцию аутентификации. На наш взгляд, этого делать не рекомендуется. Оставьте один режим, который будет достаточно безопасным для всех возможных областей применения. Разница в объеме вычислений для разных режимов шифрования не так уж велика, а криптография редко является узким местом в производительности совре- менных компьютеров. Помимо того что это сделает систему менее сложной, вы застрахуете пользователя и от потенциальной опасности, связанной с вы- бором заведомо слабых шифров. Ведь если правильный выбор функций шиф- рования и аутентификации сложен даже для разработчика, неужели с ним справится обычный пользователь? 9.4. Качество кода 169 9.4.2 Модуляризация Даже после удаления многочисленных параметров и настроек система все равно останется сложной. Существует один основной прием, позволяю- щий сделать эту сложность хоть немного более управляемой: модуляризация. В этом случае система разбивается на отдельные модули, после чего каждый из них разрабатывается, анализируется и реализуется. Безусловно, вы уже не раз встречались с модуляризацией. В криптогра- фии же правильная разбивка на модули играет еще более важную роль. Ранее мы уже рассматривали криптографические объекты и функции в качестве от- дельных модулей. Интерфейс модуля должен быть простым и понятным. Его поведение должно соответствовать разумным ожиданиям пользователя это- го модуля. Приглядитесь к интерфейсам своих модулей. Зачастую они вклю- чают в себя средства или настройки, предназначенные для решения задач какого-нибудь другого модуля. Если это возможно, выбросите такие сред- ства. Каждый модуль должен заниматься только собственными проблемами. По своему опыту мы знаем, что наличие в интерфейсе модуля “странных” средств практически всегда является результатом неадекватного проектиро- вания. Такое программное обеспечение определенно требует переделки. Правильная разбивка на модули играет особенно важную роль, поскольку это единственный имеющийся у нас эффективный способ борьбы со сложно- стью. Если действие какой-нибудь настройки ограничивается одним моду- лем, она может быть проанализирована в контексте этого модуля. Тем не менее, если настройка изменяет внешнее поведение одного модуля, она мо- жет повлиять и на другие. Если у нас есть 20 модулей, каждый из которых обладает двоичным параметром, изменяющим поведение этого модуля, у си- стемы появляется более миллиона различных конфигураций. Для проверки безопасности системы нам придется проанализировать каждую из этих кон- фигураций, что, разумеется, невыполнимо на практике. Мы обнаружили, что большинство параметров и настроек добавляются к системе для повышения ее эффективности. Это одна из распространенных проблем программной инженерии. Многие системы содержат так называемые оптимизации, которые на деле оказываются бесполезными, непродуктивными или же незначительными, поскольку они оптимизируют совсем не те части системы, которые образуют узкое место. Поэтому мы довольно скептически относимся к оптимизациям, обычно не уделяя им внимания. Мы тщатель- но прорабатываем структуру системы и пытаемся убедиться, что она может выполнять сразу большие “порции” работы. В качестве типичного примера можно привести старую IBM PC BIOS. Ее процедура, выполняющая печать символа на экране, принимала в качестве аргумента один символ. Практиче- ски все время работы этой процедуры шло на выполнение массы служебных |