Мельников Д. А. - Информационная безопасность открытых систем - 2013

Такая квитанция будет включать подтверждение получения д а н н ы х в форме ЭЦП (или цифрового отпечатка), вычисленной по всей последовательности данных, входящих в полученное со­ общение, в момент приема последнего.

Когда используется метод ЭЦП, то доказательством являет­ ся подписанная квитанция.

Существуют два варианта применения СЛНТ: в условиях отсутствия ДТС или с привлечением ДТС, выступающей в роли центра доставки.

5.7. СЛНТ в системах хранения и ретрансляции

В системе хранения и ретрансляции сообщение доставляет­ ся от его отправителя до его получателя, проходя при этом через одну или несколько промежуточных систем (intermediary), име­ нуемых посредниками доставки (transfer agent), или ретрансля­ торами. В таких системах передача сообщения включает в себя не только связь между отправителем и получателем, но и связь между отправителем и ретранслятором, связь между получателем и ретранслятором и связь между ретрансляторами. СЛНТ может применяться отдельно на каждом ретрансляционном участке, ис­ пользуемом для доставки сообщения до конечного получателя.

СЛНТ с подтверждением (доказательством) источника дан­ ных (Non-repudiation with proof of origin service) обеспечивает защиту от ложного отказа отправителя от факта передачи им со­ общения или его компонентов. Доказательством, полученным этой службой, могут воспользоваться получатель или ретран­ сляторы.

СЛНТ с подтверждением (доказательством) доставки дан­ ных (Non-repudiation with proof of delivery service) обеспечивает защиту от ложного отказа получателя от факта получения им сообщения или его компонентов. Доказательством, полученным этой службой, могут воспользоваться отправитель или ретран­ сляторы.

СЛНТ с подтверждением (доказательством) получения со­ общения для ретрансляции (Non-repudiation with proof of submis­ sion service) обеспечивает защиту от ложного отказа посредника доставки (ретранслятора) от факта получения им сообщения для

284

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

СЛНТ с подтверждением (доказательством) передачи со­ общения, подлежащего ретрансляции (Non-repudiation with proof of transport service) обеспечивает защиту от ложного от­ каза посредника доставки (ретранслятора) от факта передачи им сообщения (либо получателю, либо другому ретранслятору). Доказательство, полученное этой службой, используется отпра­ вителем.

СЛНТ с подтверждением (доказательством) участия в про­ цедуре доставки сообщения (Non-repudiation with proof of trans­ fer service) обеспечивает защиту от ложного отказа посредни­ ка доставки (ретранслятора) от собственной ответственности за доставку сообщения (от собственного участия в процедуре доставки сообщения). Эта служба используется в случае уча­ стия нескольких посредников доставки (ретрансляторов) в процедуре доставки сообщения. Когда ретранслятор, первым принявший сообщение, передает его второму ретранслятору, то последний может предоставить первому доказательство того, что он взял на себя ответственность по дальнейшей доставке сообщения. Если в процедуре доставки сообщения участвуют более двух посредников доставки (ретрансляторов), то СЛНТ может также использоваться между вторым и третьим ретран­ сляторами, и т.д.

Все перечисленные варианты использования СЛНТ даны в табл 5.1.

285

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

5.8. Восстановление в СЛНТ

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

286

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

Если СЛНТ использует закрытые криптографические клю­ чи, то может возникнуть следующая ситуация (рис. 5.4).

С Некорректный маршрут

Рис. 5.4. Использование мошенником скомпрометированного ключа стороны А

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

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

287

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

Для выхода из такой ситуации необходимо попытаться узнать, когда точно было подписано сообщение (время под­ писи). Так как время появления сообщения, сформированного мошенником С, не может быть достоверным, то необходимо об­ ратиться в ДТС для формальной регистрации сообщения, кото­ рую можно осуществить одним из следующих способов (или ис­ пользовать оба):

•копирование сообщения и ЭЦП в массив данных для проведения последующей аудиторской проверки (т.е. ис­ пользование нотариуса);

•применение скрепляющей ЭЦП, вычисленной по все по­ следовательности символов сообщения и включающей дату и время регистрации, которые были получены от не­ зависимой ДТС (t.e. Службы меток времени).

Вследствие необходимости выполнения этой процедуры мошенник мог бы неумышленно задокументировать реальное время и дату ЭЦП. В дальнейшем судья смог бы вынести моти­ вированное судебное решение об ответственности потерпевшей стороны А в зависимости:

•от временного интервала между датой/временем появле­ нием сообщения и датой/временем формирования скре­ пляющей подписи, который должен укладываться в пре­ делы достаточно небольшого временного окна (например 24 часа);

•от временного интервала между датой/временем появ­ лением сообщения и датой/временем формального объ­ явления о потере или компрометации ключа.

288

В данном случае эффективность неправомерного исполь­ зования потерянного или скомпрометированного криптоклю­ ча будет снижаться с уменьшением длительности временного окна, в течение которого разрешается зарегистрировать данные в Службе меток времени.

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

При урегулировании споров играют важную роль следую­ щие значения времени:

•время, в которое сторона А сообщила о компрометации. Сторона А будет отвергать все сообщения, которые по­ сле этого момента времени могли бы представлены как подписанные (целесообразно, чтобы использование за­ крытого ключа было прекращено сразу после того, как сторона А узнает о его компрометации);

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

5 .9 . В з а и м о д е й с т в и е с о С л у ж б о й е д и н о г о к а т а л о га

ЭЦП может быть проверена с использованием соответствую­ щего открытого ключа. Когда открытый ключ, содержащийся в СЕРТ|ИБ пользователя, представлен в Службе единого каталога, корректность ключа проверяется путем обращения к известному

289

УЦ с запросом о предоставлении его открытого ключа (проверить ЭЦП УЦ в сертификате ключа пользователя).

Так как УЦ, выпустивший СЕРТ|ИБ, может изменить свой открытый ключ уже после того, как был выдан СЕРТ|ИБ, необ­ ходимо иметь средства для проверки корректности «устаревше­ го» открытого ключа. В связи с тем, что обычно известен только тот ключ, который является действующим открытым ключом УЦ, необходимо наличие связи между действующим открытым ключом и «устаревшими» открытыми ключами. Вследствие того, что получатель не осведомлен об изменениях ключей УЦ, ответственность за предоставление возможности и способов проверки их «старых» СЕРТ|ИБ несут различные УЦ. Это мо­ жет быть достигнуто следующими двумя способами:

•путем заверения каждого устаревшего открытого ключа УЦ с помощью действующего открытого ключа УЦ;

•путем заверения каждого устаревшего открытого ключа УЦ с помощью следующего открытого ключа УЦ (при­ менение последовательности (цепочки) сертификатов).

Впервом случае существует возможность прямой проверки подлинности устаревшего открытого ключа УЦ, который соот­ ветствует закрытому ключу, используемому УЦ для выпуска оригинального СЕРТ|ИБ.

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

ПРИМЕЧАНИЕ. Если существует возможность компромета­ ции старого открытого ключа УЦ, то первый метод более предпо­ чтителен, так как при использовании второго метода цепочка сер­ тификатов, определяющая путь к старому открытому ключу УЦ,

290

могла быть взломана, и таким образом старые открытые ключи У Ц

могли стать полностью скомпрометированными.

В Службе единого каталога УЦ не сохраняет записи о СЕРТ|СО других УЦ или об их пользователях, когда сроки дей­ ствия сертификатов истекли. Более того, пользователь доказа­ тельством или ДТС должны накапливать всю необходимую до­ ступную информацию (включающую списки аннулированных сертификатов, даже если они пустые), чтобы доказать, что кон­ кретный открытый ключ был юридически действующим в не­ который момент времени.

СЕРТ|СО содержит дату своего выпуска УЦ. Кроме этого, он может содержать и другую дату, которая могла бы оказать содей­ ствие при урегулировании споров в некоторых ситуациях: дата, когда пользователь был еще уверен в том, что его ключ не был скомпрометирован. Все подписи, сформированные пользовате­ лем до этой даты, будут определены им как действительные. Если такая дата не указана, так как предполагается, что это наихудший случай, то все подписи, сформированные в течение реального срока действия СЕРТ|ИБ, могли бы рассматриваться как недей­ ствительные. Это имеет огромное значение в коммерческой сфе­ ре, особенно это важно для пользователя, подписавшего доку­ мент, который по-прежнему считается действительным, даже в случае когда ключ, используемый для подписи сообщения, был потерян. Несмотря на то что наличие этой даты в СЕРТ|СО яв­ ляется необязательным, эта дата будет востребована, если ключ соответствующего сертификата используется СЛНТ.

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

•УЦ являются полностью надежными и для них известен действующий открытый ключ;

291

•УЦ являются надежными относительно выпуска серти­ фиката УЦ и СЕРТ|ИБ пользователей;

•УЦ являются надежными относительно выпуска только СЕРТ|ИБ пользователей (но не сертификата УЦ).

Такая информация должна свободно распространяться и быть доступным для пользователя доказательством. Последний может выбрать форму СЕРТ|ИБ, в которой содержится период действия сертификата. Определены две формы сертификатов политики безопасности: сертификаты политики безопасности, в которых закреплена ответственность судьи за хранение записи о таких сертификатах, и сертификаты политики безопасности, в которых закреплена ответственность получателя за хранение записи о таких сертификатах.

Общая структура службы обеспечения неотказуемости пред­ ставлена в табл. 5.2.

292

Таблица 5.2 (продолжение)

Объект/субъ­ ДТС, Центр безопасности ект

мнеотказуемо­

Ести

293