В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 21. Практические аспекты PKI и оставить достаточный запас времени, чтобы все неоконченные тран- закции могли завершиться прежде, чем срок действия ключа будет ис- черпан. • Окончание срока действия. В конце своего жизненного цикла ключ устаревает и больше не считается действительным. Как определяют этапы жизненного цикла ключа? Самое распространен- ное решение — явно задать в сертификате время перехода к каждому следу- ющему этапу. Такой сертификат будет содержать дату начала этапа распро- странения, дату начала этапа активного использования, дату начала этапа пассивного использования и дату окончания срока действия. К сожалению, со всеми этими датами необходимо ознакомить и пользователя, так как они влияют на способ работы сертификата. Между тем для среднестатистических пользователей все это может оказаться слишком сложно. Более гибкая схема подразумевает наличие централизованной базы дан- ных, которая будет содержать список этапов жизненного цикла для каждого ключа. Этот подход, однако, влечет за собой массу совершенно новых про- блем безопасности, которыми мы предпочли бы не заниматься. Кроме того, если у вас есть список отзыва сертификатов, он может аннулировать содер- жимое базы данных и привести к моментальному устареванию ключа. Ситуация еще более усложняется, если пользователь А хочет применять один и тот же ключ в нескольких различных инфраструктурах открытого ключа. В общем случае этот подход кажется нам неудачным, но иногда без него просто не обойтись. Предположим, пользователь А носит с собой неболь- шой модуль, защищенный от несанкционированного вмешательства. Этот модуль содержит закрытые ключи пользователя А и выполняет вычисле- ния, необходимые для создания цифровой подписи. Подобные модули имеют ограниченный объем памяти для хранения данных. Сертификаты открытых ключей пользователя А могут храниться в корпоративной сети без каких- либо ограничений на их размер, но маленький модуль не сможет вместить в себя неограниченное количество закрытых ключей. В подобных ситуациях пользователю А приходится применять один и тот же ключ в нескольких различных инфраструктурах. Из этого также следует, что жизненный цикл ключа должен быть одинаков для всех инфраструктур открытого ключа, в которых состоит пользователь А. Скоординировать подобные параметры довольно сложно. Если вам когда-нибудь придется работать с системами такого рода, убе- дитесь, что цифровая подпись, используемая в одной инфраструктуре от- крытого ключа, не будет фигурировать в других инфраструктурах. Всегда придерживайтесь одной и той же схемы цифровой подписи, например опи- санной в разделе 13.7. Подписываемая строка байтов никогда не должна сов- 21.3. Почему ключи изнашиваются 367 падать для двух разных приложений или инфраструктур открытого ключа. Этого легко добиться, включив в подписываемую строку данные, которые уникальным образом идентифицируют приложение и инфраструктуру от- крытого ключа. 21.3 Почему ключи изнашиваются Уже не раз отмечалось, что ключи следует периодически менять, но по- чему? В идеальном мире один и тот же ключ мог бы использоваться на протя- жении очень долгого времени. При отсутствии слабых мест в защите системы злоумышленнику не остается ничего другого, как проводить поиск путем пол- ного перебора вариантов. Теоретически это сводит нашу проблему к задаче выбора ключей достаточно большого размера. К сожалению, наш мир не идеален. Секретность ключа всегда находит- ся под угрозой. Ключ нужно где-то хранить, и злоумышленник может туда добраться. Ключ также может находиться в использовании, а каждое при- менение ключа несет в себе еще одну потенциальную угрозу его безопасно- сти. Ключ должен быть передан из места своего хранения туда, где будут проводиться вычисления. Зачастую процесс передачи ключа ограничивается рамками одного компьютера, но и это открывает для злоумышленника оче- редную возможность нападения. Если злоумышленник может прослушивать канал общения, который применяется для передачи ключа, он непременно получит копию этого ключа. И наконец, над ключом выполняются разнооб- разные криптографические операции. Мы не знаем сколько-нибудь полезных криптографических функций, которые бы имели доказательства своей без- опасности. В их основе обычно лежат сомнительные аргументы наподобие: “Пока что никому из нас не удалось обнаружить способ нападения на эту функцию, поэтому она выглядит вполне безопасной” 1 . Чем дольше мы храним ключ и чем больше его используем, тем выше ве- роятность того, что злоумышленнику удастся его взломать. Если мы хотим ограничить вероятность того, что злоумышленник узнает ключ, следует огра- ничить время жизни этого ключа. По сути, ключ как будто изнашивается. Существует еще одна причина, требующая ограничить время жизни клю- ча. Предположим, в системе произойдет что-нибудь неприятное и злоумыш- 1 То, что часто называют “доказательством безопасности” криптографических функций, на деле таковым не является. Подобные доказательства представляют собой не более чем простое логическое приведение: если мы можем взломать функцию A, то можем взломать и функцию Б. Это позволяет сократить количество примитивных операций, выполнение которых предполагается безопасным, однако это ни в коей мере не является реальным доказательством безопасности. |