книги / Практическая криптография

17.1.4 Выполнение транзакций в режиме реального времени

Следующий пример основан на опыте работы Нильса с системами элек­ тронных платежей. Чтобы обслуживать платежи “на лету”, банку нужна си­ стема финансовых транзакций, работающая в режиме реального времени. Чтобы обеспечить возможность аудита, подобная система должна соответ­ ствовать нескольким требованиям. Прежде всего, в системе должна суще­ ствовать строгая последовательность транзакций. Для каждых двух тран­ закций А и В очень важно знать, какая из них была выполнена первой, поскольку результат одной из них может зависеть от того, была ли уже вы­ полнена другая. Самый простой способ зафиксировать последовательность выполнения транзакций — это присвоить каждой из них временную метку. Данный подход, однако, сработает только в том случае, если у нас будут надежные часы.

Ненадежные часы могут показать неправильное время. Если часы слу­ чайно станут показывать время в прошлом, ничего не произойдет: легко про­ верить, что текущее время больше временнбй метки последней выполненной транзакции. Настоящие проблемы возникнут тогда, когда часы станут по­ казывать время в будущем. Предположим, в течение получаса выполнения транзакций часы показывали 2020 год. Мы не можем просто изменить вре­ менные метки этих транзакций: изменять финансовые записи вручную не допускается. Мы также не можем выполнять новые транзакции, временные метки которых будут находиться ранее 2020 года, так как это нарушило бы порядок выполнения транзакций, который определяется именно временнбй меткой. Данную проблему, разумеется, можно решить, однако иметь надеж­ ные часы все же предпочтительнее.

17.2Использование микросхемы датчика времени

Большинство настольных компьютеров содержат микросхему датчика времени и маленькую батарею. Это самые настоящие маленькие цифровые часы. Именно с их помощью компьютер определяет, сколько сейчас времени, когда его включают после ночного “сна”. Так почему же просто не восполь­ зоваться временем этих часов?

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

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

Датчики времени, встроенные в ббльшую часть аппаратного обеспече­ ния, не обладают той степенью надежности и защищенности, которая нам нужна. На протяжении последних 10 лет мы несколько раз сталкивались со сбоями микросхемы датчика времени. Что еще хуже, эти сбои происходили спонтанно, без всякого участия злоумышленников, пытающихся повредить наши часы. Большинство сбоев подобного рода довольно просты. В старом компьютере батарея может “сесть” и часы остановятся либо будут “сброше­ ны” на 1980 год. Кроме того, в один прекрасный день вы можете включить компьютер и обнаружить, что часы сами собой перевелись на какой-то день 2028 года.

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

17.3Виды угроз

Существует несколько типов атак на систему с часами.

17.3.1Перевод часов назад

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

Не менее интересным объектом атак являются автоматизированные зада­ чи. Компьютер, стоящий в отделе кадров, автоматически начисляет зарплату в конце каждого месяца, используя прямое зачисление на депозит по пла­ тежной ведомости. Выполнение автоматизированных задач наподобие этой инициирует программа, которая проверяет текущее время и просматривает список назначенных задач. Постоянный перевод часов назад может привести

к повторяющемуся выполнению одних и тех же задач. Если выполнение за­ дачи должно начаться в полночь, злоумышленник переводит часы на 23:55 (11:55 р .т.) и ждет, пока система начнет выполнять задачу. По окончании выполнения задачи злоумышленник снова переводит часы назад. Это может повторяться до тех пор, пока запасы средств на банковском счете компании не будут исчерпаны.

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

17.3.2Остановка часов

Каждый разработчик живет с инстинктивным пониманием того, что вре­ мя не стоит на месте. Это негласное предположение слишком очевидно даже для того, чтобы фиксировать его в документации. Системы, которые созда­ ют разработчики, основаны на нормальном поведении времени. Но, если часы останавливаются, время будто бы замирает. Многие процессы не будут завер­ шены, а многие системы начнут вести себя непредсказуемо.

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

Другие проблемы могут касаться программ, отображающих изменение данных в режиме реального времени. Предположим, разработчик графиче­ ского интерфейса использует простую систему для отображения текущего по­ ложения дел на дисплее биржевого брокера. Каждые 10 секунд содержимое дисплея обновляется. Но не все отчеты о выполнении финансовых транзак­ ций поступают с одинаковой скоростью из-за различных задержек. Простое отображение полученных данных может создать несогласованное представле­ ние о сложившейся финансовой ситуации. Возможно, об одной части транзак­ ции уже был подан отчет, а о другой еще нет. Поступление денежных средств на банковский счет может отобразиться еще до фактического перемещения акций. Бухгалтеры не любят получать отчеты, суммы в которых не сходятся.

Во избежание подобных проблем разработчик применяет хитрый прием. Каждому отчету о выполнении финансовой транзакции присваивается вре-

менн&я метка, после чего он помещается в базу данных. Чтобы создать согла­ сованный отчет, разработчик выбирает конкретный момент времени и отоб­ ражает финансовую ситуацию, соответствующую тому моменту. Например, если отчет от самой медленной системы поступает с задержкой в пять се­ кунд, разработчик отображает положение дел, которое существовало семь секунд назад. Это немного увеличивает задержку, с которой данные посту­ пают на дисплей брокера, однако гарантирует их согласованность. Если же часы неожиданно остановятся, на дисплее будет постоянно отображаться од­ на и та же ситуация: положение дел по состоянию на семь секунд назад от­ носительно времени, которое показывают испорченные часы. Катастрофа!

17.3.3Перевод часов вперед

Перевод часов вперед заставляет компьютер думать, что он живет в буду­ щем. Это приводит к появлению множества простых атак типа “отказ в обслу­ живании”. Если часы будут переведены на четыре года вперед, все транзак­ ции с участием кредитных карточек будут неожиданно отклонены, так как карточки окажутся недействительными. Вы также не сможете заказать авиа­ билеты через Internet, поскольку расписания полетов на четыре года вперед еще не существует.

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

Наш друг однажды столкнулся с подобной проблемой при разработке бил­ линговой системы. Из-за ошибки в программном обеспечении часы переско­ чили на 30 лет вперед. Как следствие, биллинговая система начала предъяв­ лять своим клиентам горы неоплаченных счетов за 30 лет. В данном случае это не привело к прямым финансовым потерям, но если бы система автома­ тически снимала деньги с банковских счетов или кредитных карточек, ре­ зультат был бы весьма плачевным. Разумеется, это никак не способствовало установлению хороших отношений с клиентами.

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

аутентификацию временных данных, чтобы злоумышленник не смог обма­ нуть компьютер. Разумеется, для выполнения подобной аутентификации си­ стеме требуется некоторая инфраструктура ключей. В качестве общего клю­ ча, используемого совместно с сервером времени, можно было бы применять ключ симметричного шифрования и настраивать его вручную, но настрой­ ка ключей вручную — занятие не из приятных. Обмен ключами с сервером времени можно было бы проводить и с помощью инфраструктуры открытого ключа (PKI). К сожалению, как отмечается в главе 19, “PKI: красивая мечта”, большинству систем PKI нужны часы, что напоминает старую добрую исто­ рию о курице и яйце. Будьте крайне осторожны, полагаясь на криптографи­ ческую защиту, которую предоставляют протоколы синхронизации времени. В этом случае от безопасности протокола может зависеть безопасность всей вашей системы, а мы еще не видели ни одного криптографического обзора подобных протоколов.

17.5Проблема одного и того же состояния

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

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

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

330 Глава 17. Часы

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

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

Аналогичного эффекта можно добиться с помощью аппаратного генера­ тора случайных чисел. Он позволяет встроенному компьютеру изменять свое поведение после каждой перезагрузки.

А как быть, если в системе нет датчика времени или генератора случай­ ных чисел? К сожалению, это оборачивается большими проблемами. Разуме­ ется, проявив смекалку, вы можете попытаться извлечь случайность из фа­ зового сдвига синхронизирующих импульсов между локальным резонатором и сетевым источником времени, но получить достаточное количество энтро­ пии за такое короткое время практически невозможно. Вряд ли кто-нибудь захочет, чтобы встроенный компьютер загружался 10 минут кряду!

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

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

Существует еще одно возможное решение, хотя оно редко применимо на практике. Иногда в энергонезависимую память удается поместить счетчик перезагрузок. Значение этого счетчика будет увеличиваться на единицу при каждой перезагрузке компьютера. Данное решение изобилует всевозможны­ ми недостатками. Некоторые типы энергонезависимой памяти могут претер­ петь лишь несколько тысяч обновлений. Постоянное обновление счетчика, хранящегося в такой памяти, приведет к быстрому износу компьютера. Еще некоторые типы энергонезависимой памяти могут быть запрограммированы только при наличии дополнительного напряжения, которое в обычных усло­ виях зачастую недоступно. В некоторых системах мы можем лишь устанав­ ливать определенные биты энергонезависимой памяти или очищать все ее со­ держимое. Последняя возможность нас не устраивает, поскольку в результа­ те полной очистки памяти мы бы потеряли главную программу компьютера. Впрочем, даже если мы справимся со всеми перечисленными выше пробле­ мами, нам будет крайне сложно модифицировать энергонезависимую память таким образом, чтобы значение счетчика всегда гарантированно увеличива­ лось, даже если в произвольные моменты времени система будет неожиданно отключаться от электропитания. На практике мы встречали лишь несколько ситуаций, в которых данное решение оказывалось действительно жизнеспо­ собным.

17.6Время

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

332 Глава 17. Часы

своими ноутбуками, могут изменять установленное на них время в соответ­ ствии с местным временем, что еще более усугубит проблему.

Очевидное решение — использовать время UTC. Это международный стандарт времени, основанный на использовании атомных часов, который широко применяется во всем мире. Любой компьютер может отслеживать смещение местного времени относительно времени UTC и использовать эти знания для взаимодействия с пользователем.

Время UTC имеет один недостаток — дополнительные секунды (leap se­ conds). Чтобы сохранить синхронизацию времени UTC с периодом вращения Земли, каждые несколько лет вводится дополнительная секунда. До сих пор все дополнительные секунды были положительными: в последний день кон­ кретного месяца выбирается минута, которая будет длиться 61 с. Теорети­ чески дополнительная секунда может быть и отрицательной. Все зависит от вращения Земли. Проблема дополнительных секунд состоит в том, что они непредсказуемы. Игнорирование дополнительных секунд приводит к неточ­ ности измерения времени, если соответствующий временной интервал вклю­ чает в себя дополнительную секунду. Вообще-то данную проблему нельзя назвать криптографической, но, если вы хотите создать хорошие часы, ее нельзя не учитывать. В любом программном обеспечении всегда предполага­ ется, что в каждой минуте содержится ровно 60 с. Если вы синхронизируете свою систему непосредственно со шкалой времени UTC, неожиданная вставка дополнительной секунды может вызвать проблемы. В большинстве случаев это приведет к тому, что значения внутренних часов на протяжении одной секунды будут повторяться дважды. Это второстепенная проблема, но она нарушает уникальность и монотонность значений времени.

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

Более подробно о различных шкалах времени, таких, как UTC, GMT, TAI или UT1, можно прочитать в Internet.

17.7Заключение

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

Глава 18

Серверы ключей

Пришло время вплотную заняться управлением ключами. Это, без со­ мнения, самый трудный момент всех криптографических систем. Именно по­ этому мы решили рассмотреть управление ключами в конце книги. Мы уже объясняли, как шифровать данные, проводить их аутентификацию и согласо­ вывать секретный ключ между двумя участниками общения. Теперь нужно найти способ, с помощью которого пользователи А и Б могли бы идентифи­ цировать друг друга по Internet. Вы вскоре убедитесь, что сложность данной проблемы разрастается с быстротой снежного кома. Управление ключами является таким трудным еще и потому, что вместо математических формул в нем задействованы люди, а понять и предсказать человеческую логику на­ много сложнее.

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

Один из способов управления ключами — создание доверенной сущности, которая будет раздавать пользователям все необходимые ключи. Назовем такую сущность сервером ключей (key server).