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

блему на другой уровень.

Чтобы проверять цифровую подпись, автоматизированной системе нужен доступ к ключу верификации подписи (signature vйrification key) в реаль­ном времени, а этот ключ тоже может быть изменен. Если хэшировать ключ, его сертификат и всю цепочку доверия, то как их всех аутентифи-цировать? Любой из этих элементов может быть изменен, если только и они, и соответствующая логика не встроены в непрограммируемое обору­дование. Однако исо^ходимосп, в дополнительных уровнях проверки оп­ределяется требуемым уровнем защиты данных.

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

ку и изменить механизм                                        хэш-кодов так, чтобы он извлекал

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

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