Наиболее важным является вопрос: как следует построить надежную
систему на смарт-картах? Без этого продукт немного стоит. Однако, до сих
пор не существует общепринятого мнения о том, из каких компонент состоит
надежная система безопасности. В различных инженерных дисциплинах конкретная
природа надежности изменяется от одной дисциплины к другой. Строители мостов
знают, что наиболее вероятные дефекты, такие как некачественная сталь,
испорченный бетон или неблагоприятные погодные условия, просто уменьшают
сопротивление материала. Поэтому обычное правило проектирования мостов
состоит в том, что теоретическое разрушающее воздействие для оптимальных
материалов надо брать с шестикратным запасом, и чтобы доказать надежность,
образец реального материала подвергается испытаниям на значительной, вплоть
до трехкратной, перегрузке.
С другой стороны, в авиастроении многие аварии происходят из-за отказа критически важных компонент, и поэтому проектировщики используют дублирование. Для очень важных функций этот подход может быть расширен вплоть до закладывания в проект дублирования в различных формах: например, обычный современный самолет определяет свое положение в воздухе используя две электронные системы, которые используют гирокомпасы, управляемые от основной силовой сети. Но если обе эти системы выйдут из строя по какой-либо причине, то существует технология искусственного горизонта 1950 года на пневматическом гироприводе и модель 1920 года -- управляемый от батарей индикатор поворота и снижения.
Но ни проектирование с запасом, ни дублирование недостаточны для проектировщика систем безопасности. Последовательное применение нескольких криптографически слабых алгоритмов совсем не обязательно приведет к тому же эффекту, что и использование одного хорошего алгоритма. Непродуманное использование избыточности в компьютерных системах может быть опасным, поскольку способность к быстрому восстановлению может скрыть просчеты, которые в ином случае были бы обнаружены и исправлены.
Известно, что причиной большинства нарушений безопасности как в гражданских,
так и в военных компьютерных системах являлись грубые просчеты, и этот
факт показывает, что в данной области надежность - такая же проблема, как
и для людей строящих мосты и самолеты. Можно ожидать, что проблема даже
теснее связана с фундаментальными принципами, поскольку мы должны рассмотреть
ее суть на нескольких уровнях. Рассмотрим последовательно уровни алгоритмов,
протоколов, приложений и управления.
Надежность
алгоритмов и их взаимодействий
В течение ряда лет криптографы довольствовались выполнением хеш-функциями
условий односторонности и отсутствия коллизий. Затем в 1992 году Т.Окамото
предложил третье условие - отсутствие корреляции. Функция h называется
свободной от корреляции, если трудно подобрать такие входы M и M', что
значения h(M) и h(M') отличаются только в нескольких битах. Он предположил,
что свойство быть свободным от корреляции является более сильным, чем свойство
отсутствия коллизий.
В прошлом году была показана справедливость этого предположения. На
самом деле было показано, что существует много свойств желательных для
хеш-функций, таких как отсутствие зависимости по умножению (нельзя найти
такие X, Y и Z, что h(X)h(Y) = h(Z)), отсутствие зависимости по сложению
(то же для X, Y и Z, так что h(X) + h(Y) = h(Z)). Также было показано,
что эти свойства независимы друг от друга, для чего были построены функции,
которые некоторыми свойствами обладают, а некоторыми нет. Это дало понимание
того, что по крайней мере на уровне приложений мы должны иметь точное определение
свойств, которыми должны обладать используемые криптографические примитивы.
Криптографические алгоритмы не являются предметом первостепенного внимания
проектировщика коммерческих систем. Рассмотрим тему вкратце, поскольку
проведенные исследования по взаимодействию алгоритмов дают понимание того,
что надежность алгоритма характеризует его полная определенность. Различные
авторы рассматривали проблему предотвращения нежелательного взаимодействия
между криптографическими алгоритмами, такими как хеш-функция и алгоритм
цифровой подписи. Начиная с работ У.Диффи и М.Хеллмана 1976 года было осознано,
что хеш-функция должна быть односторонней, то есть просто вычислить h(M)
зная M, но очень трудно подобрать M такое, чтобы получалось точно h(M).
Это свойство трудно формализовать для невыраженной явно функции. Поэтому
было предложено второе свойство - отсутствия коллизий - состоящее в том,
что трудно найти два различных входа M и M' таких, что h(M) = h(M').
Надежность
протоколов и операционных систем
Надежность криптографических протоколов обсуждалась в академической
литературе с мая 1993 года: появилось три работы в которых она предлагалась
в качестве решения проблемы проектирования схем аутентификации.
Полная определенность относит к соответствующим категориям и упомянутые выше проблемы: короткие имена, недостаточная обновляемость и недостаточность контекста - все они являются нарушениями полной определенности. В каждом случае некоторая информация, которую оба агента подразумевают, не выражается явно в конверте безопасности и, поэтому, ей может манипулировать злоумышленник.
Полностью определенные протоколы критиковались как дорогие. У.Ву и С.Лэм недавно провели эксперименты, начав с полностью определенного протокола и пытаясь выяснить, какая информация может быть удалена. Однако, философская точка зрения состоит в том, что оптимизация - это процесс замены того, что работает на то, что почти работает, но обходится дешевле. Если "оптимизированная" версия не является более дешевой, процесс не является оправданным. В действительности, невыраженная явно в криптографическом протоколе информация (такая как "это сообщение 3 в протоколе Цербер версии 6 подпротокола 17") уже известна обеим сторонам и поэтому отсутствуют дополнительные затраты на ее передачу. Большинство реальных протоколов либо используют быстрые симметричные шифры, либо используют быстрые хэш-функции для сокращения сообщений перед вычислением цифровой подписи. Неясно, существует ли вообще значимая стоимость вычислений.
В действительности, протоколы, используемые в UEPS, как эффективны,
так и надежны. Когда они проектировались, все подчинялось двум целям: первая
- уменьшение длины кода и, как следствие, сокращение коммуникационного
протокола (имелся ограниченный объем памяти и очень медленные устройства
интерактивного взаимодействия) и, вторая - обеспечение надлежащей верификации
протокола.
Надежность
прикладной программы
У многих более старых банковских систем существовала проблема, состоящая
в том, что прикладные программы имели свободу выбора в том, какие свойства
безопасности реализовывать. Рассмотрим, например, модули безопасности,
используемые в сетях банкоматов, которые шифруют персональные идентификационные
коды. Эти устройства возвращают целые серии кодов возврата, которые могут
быть значимыми для менеджера безопасности: например, если программист начнет
несанкционированные эксперименты с боевыми ключами, менеджер, вероятно,
получит сообщение об ошибке четности ключа.
Ясно, что будет разумно отображать на мониторе эти коды возврата и очевидное
решение состоит в том, чтобы написать драйвер, который перехватывает все
ненормальные коды завершения из модуля безопасности и привлекает к ним
внимание администратора или персонала службы безопасности. Однако, ни одно
из рассмотренных нами ведомств или институтов не реализовало правильный
мониторинг. Поскольку система будет "работать" без мониторинга, а драйверы
устройств сложно писать, работа никогда полностью не выполняется.
Одно из преимуществ надежной компьютерной основы, построенной как на
смарт-картах, так и на модулях безопасности, состоит в том, что можно спроектировать
транзакции таким образом, чтобы прикладная программа выполняла все необходимые
проверки. Это было сделано в UEPS посредством связывания каждого сообщения
со следующим. Таким образом программист, который попытается взломать систему,
исключив некоторые сообщения, обнаружит, что он не может вообще заставить
систему работать.
Конечно, эта стратегия может быть более продуктивной на распределенных
надежных компьютерных основах, какие можно реализовать на смарт-картах.
При этом проверки могут быть сделаны более всеобъемлющими. Можно управлять
такой информацией состояния безопасности как коды возврата и определенные
аспекты истории транзакций. Более интеллектуальным является решение, когда
компоненты надежной компьютерной основы размещены в каждом узле сети, а
не на сервере безопасности, реализованном на мощном компьютере, где выполняется,
возможно, сотня критических по безопасности процессов, таких как операции
со счетами, межбанковские расчеты и аудит.
Предположим например, что мы разрешим персоналу отделения банка инициализировать
карточки для клиентов. В странах со слабыми телекоммуникациями мы вынуждены
будем выполнять большую часть операций в режиме off-line, так как иного
выбора нет. В системе UEPS из карты операциониста считывается несколько
криптографических ключей и иных данных инициализации в карту клиента. Предположим,
что ожидается, что около 1% персонала отделения банка попытаются присвоить
деньги в течение среднестатистического года. Поэтому, вероятно, мы решим
идентифицировать карту операциониста не только для каждой клиентской карты,
но и для каждой транзакции. В этом случае мы можем обеспечить распределенную
систему аудита и открыть новые возможности для вскрытия обмана.
Ключевым является факт, что смарт-карты - это объекты, которые могут
поддерживать состояние безопасности. Это состояние не нуждается в ограничении
баланса клиентского счета. Хорошо спроектированная система будет использовать
этот факт, чтобы обеспечить более высокий уровень функциональности приложений,
чем было возможно раньше, и поручиться, что неполная, небезопасная реализация
не будет работать вообще.
В основном проблема надежности прикладной программы решается средствами
проектирования программного обеспечения. Однако, даже здесь полная определенность
играет важную роль, поскольку многие общие методики подчеркивают необходимость
формулировки требований в наиболее точно определенной форме и проверки
выполнения требований в виде набора тестов или путем построения прототипа.
Цель проверки - удостовериться, что программы правильно кодированы и тестированы.
Тем не менее, существует несколько аспектов уровня прикладной программы,
которые требуют дополнительного внимания.
Надежность
алгоритмов
Был выбран DES в качестве криптографического алгоритма, поскольку он
был привычен для клиентов, а смарт-карты с открытыми ключами не были реализованы
в 1991 году. Поскольку банковское сообщество уже рассматривало проблему
вскрытия системы путем последовательного подбора ключа как очень серьезную,
единственное средство обеспечения надежности реализованное на алгоритмическом
уровне было двойное шифрование (это можно принять как единственную черту,
которая более соответствует избыточности, чем полной определенности!).
Надежность
протокола
A -> B: K1(K2(A, B, A1))
B -> A: K1(K3(B, A, B1)) , где K3 = K2(A, B, A1)
A -> B: K1(K4(A, B, A2)) , где K4 = K3(A, B, A1)
Первоначальная цель проектирования здесь состояла в том, чтобы, во-первых,
реализовать связывание сообщений и двойное шифрование с использованием
минимально возможного объема кода и, во-вторых, сделать легче формальную
проверку протокола.
Начиная с прототипа Мегалинк, была реализована функция внесения разнообразия
в ключи. Оригинальная система имела одинаковую пару ключей K1 и K2 на каждой
карточке (хотя один загружался на фабрике, а второй при инициализации).
В новых системах только карты банковского служащего и кассовые терминалы
обладают множеством единых секретных частей, а карты пользователя обладают
ключами, производными от их серийных номеров и соответствующих мастер-ключей.
Протоколы платежей, используемые в UEPS имеют свойство надежности,
состоящее в том, что вся взаимная информация между двумя сторонами сделана
полностью определенной за счет включения в ключи сообщений. Начало протокола
между картой A и картой B, использующими ключи K1 и K2, для блоков сообщений
A1, B1, A2 ... выглядит так:
Не были повторены ошибки разработчиков банкоматов, которые забыли
обеспечить средства арбитража спорных транзакций. Определенные средства
были встроены в UEPS для разрешения конфликтов.
Во-первых, используется две подписи при каждом цифровом платеже: одна генерируется на ключе, известном только банку-эмитенту и карте покупателя, а другая генерируется на ключе, контролируемом расчетной палатой и загружаемом в карту перед тем, как она поставляется в банк. Последняя подпись проверяется перед тем, как деньги кредитуются на представленный чек, а первая будет проверяться только при арбитраже. Наличие различных подписей рассматривается как важная особенность системы, дающая начальную юридическую ответственность банка-эмитента перед пользователем. Кроме того, не следует забывать, что банки, вступающие в систему, имеют разный уровень развития автоматизации.
Еще одно свойство, не упоминавшееся ранее, печать транзакций в зашифрованном виде на чековую ленту с использованием двух различных ключей: один известен владельцу карты и банку-эмитенту но не известен магазину или расчетной палате, а другой известен магазину или расчетной палате, но неизвестен владельцу карты и банку-эмитенту. В случае судебного разбирательства взаимных претензий, суды, вероятно, примут протоколы транзакций в качестве доказательств; особенно записи, сделанные не на магнитной ленте, а на бумаге, копии которых есть и у покупателя, и у продавца.
Дополнительное преимущество наличия нескольких независимых механизмов безопасности состоит в том, что в случае технической атаки маловероятно, что все защитные механизмы будут разрушены. В конце концов некоторые из них (такие как твердые копии транзакций) не должны быть преодолены, в целях получения денег из системы, и в действительности не могут быть обойдены до тех пор, пока злоумышленник не получит доступ к карте жертвы (или банковскому модулю безопасности).
Отсюда следует, что с большой вероятностью факт нападения станет известен. Это позволит избежать возникновения бремени слишком сложных доказательств истцам, которые были в судах США в делах против банковской индустрии карт с магнитной полосой.
Завершая раздел, отметим, что существует правило, что все торговые транзакции
должны быть проведены через банк в течение 14 дней. Это означает, что в
отличие от подобной системы Мондекс, предлагаемой сейчас в Великобритании,
UEPS может вернуть деньги, которые находились на утерянной клиентом карточке
за короткий период. Функции принятия решений в спорных ситуациях являются
центральной частью традиционной банковской системы. Отказ от них, что кажется,
подразумевается во многих разработках систем электронных платежей, может
привести к возрастанию непредсказуемых рисков.
Вывод
Данный факт может использоваться в структурном подходе и первым шагом
является обеспечение хорошо определенных целей бизнеса. На следующем шаге
необходимо аккуратно сформировать модель угроз и проработать функциональные
свойства, которыми должна обладать система. В конечном счете безопасность
это не просто бинарный атрибут, а множество свойств, которые обеспечивают
возможность системе выполнять ее предназначение (проводить банковские транзакции,
помогать победить в войне или что-то еще).
Как только получим хорошо определенное множество свойств безопасности,
которыми должна обладать система, можно искать способы, с помощью которых
можно реализовать их на надежной компьютерной основе. Свойства уровня приложений
используются для того, чтобы выполнить хорошую реализацию в конкретной
операционной среде, и таким образом обеспечить точную стыковку функциональных
свойств. Принципы полной определенности также полезны, как руководящая
идея при проектировании таких технических деталей как криптографические
протоколы, на которых строится структура в целом.
Надежность, как свойство полной определенности, не нова. Эта концепция
была использована при проектировании UEPS, имеющую коммерческий успех с
1991 года. Оказалось, что не существует значимых вычислительных или коммуникационных
затрат, связанных с надежными протоколами. Единственный действительный
вклад в проектирование надежной системы безопасности состоит в дополнительных
усилиях на стадии проектирования. Но правильно сделать сначала всегда дешевле,
чем доводить систему в процессе долгой эксплуатации.
В реальном мире большинство вещей рано или поздно ломается. В сфере
традиционных инженерных разработок проблему надежности обычно пытаются
решить, используя некоторую комбинацию проектирования с запасом и дублирования.
Однако надежность компьютерной системы безопасности зависит от полной определенности
также, как все остальное.