Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

8.6. Пример ~ SESAME 521

8.6.1.

Компоненты системы SESAME

SESAME может рассматриваться как система клиент-сервер, в которой клиенты

имеют доступ к приложениям, выполняющимся на удаленных серверах. Подоб-

ная организация служит причиной разделения компонентов SESAME на три

группы, как показано на рис. 8.39. Эти три группы, соответственно

—

общие ком-

поненты защиты, компоненты защиты клиента и компоненты защиты сервера.

Их мы и обсудим далее.

Компоненты клиента Сервер защиты домена

Компоненты сервера

Спонсор

пользователя

Приложение

клиента

Клиент

АРА

Сервер

аутентификации

Сервер

атрибутов

привилегий

Менеджер

безопасности

Сервер

распространения!

ключей

Средства

проверки

РАС

Менеджер

защиты

Приложение

сервера

Рис. 8.39. Компоненты SESAME

Общие компоненты защиты

Общие компоненты защиты отвечают за аутентификацию, авторизацию и рас-

пространение ключей. Эти компоненты обычно размещаются на отдельной ма-

шине, известной под названием

сервера защиты домена {Domain

Security Server,

DSS).

Сервер

аутентификации

{Authentication

Server,

AS) отвечает за аутентифика-

цию пользователей (людей) и приложений (программ). В случае приложений

аутентификация происходит при помощи секретных ключей, хранимых в отдель-

ной базе данных, называемой

информационной базой управления защитой {Security

Management Information

Base, SMIB). База SMIB реализована в виде набора от-

дельных файлов и хранит также информацию, относящуюся к другим компонен-

там, входящим в сервер защиты домена. Пользователи аутентифицируются при

помощи секретного ключа, порождаемого, как и в системе Kerberos, из пароля,

введенного пользователем. Однако если пользователь имеет закрытый ключ, то

для аутентификации используется этот ключ.

Если Алиса захочет войти в систему, используя свой закрытый ключ, она по-

сылает AS запрос на вход вместе с сертификатом, подписанным сертифицирую-

щей организацией, и ее открытым ключом. Если все в порядке, AS в ответном

сообщении посылает сеансовый ключ, который Алиса может использовать для

связи с сервером атрибутов привилегий (о котором мы скажем чуть ниже), шиф-

522 Глава 8. Защита

руя его открытым ключом Алисы. Кроме того, ответ содержит талон для сервера

атрибутов, так же как и в Kerberos. Вдобавок сервер AS возвращает сертификат,

содержащий его собственный открытый ключ.

Основное назначение

сервера атрибутов привилегий {Privilege

Attribute

Server,

PAS) — выдавать сертификаты атрибутов со списками прав доступа клиента

к приложениям. Возвращаясь к Алисе, это означает, что она должна передать сер-

веру PAS полученный при аутентификации талон.

Алиса также посылает PAS запрос на определенные права доступа к одному

или более приложениям, с которыми она собирается работать. Этот запрос со-

провождается так называемой

криптографической

пломбой

(cryptographic

seal),

которая представляет собой хэш, рассчитанный, исходя из запрашиваемого спи-

ска прав

[168].

Пломба позволяет PAS проверить, не подправил ли кто-то этот

список. Сам список не шифруется. После получения запроса PAS проверяет,

можно ли предоставить Алисе запрашиваемые права, и если это так, собирает их

сертификате атрибутов привилегий {Privilege

Attribute

Certificate,

РАС). Более

детально мы поговорим о РАС чуть ниже. Кроме возвращения сертификата РАС

(который также запечатан), сервер атрибутов также создает новый сеансовый

ключ, который Алиса может использовать для связи с KDS. Эта информация со-

храняется в еще одном талоне.

Отметим, что если никакого общего ключа для связи между клиентом и сер-

вером в дальнейшем не требуется, Алиса может не связываться с

сервером

рас-

пространения

ключей {Key

Distribution

Server,

KDS). Однако при работе с прило-

жениями, использующими симметричные ключи, Алиса может задействовать

свой талон KDS для того, чтобы потребовать от KDS создать сеансовые ключи

для организации защищенной связи с серверными приложенршми. В SESAME

сервер KDS может быть реализован с помощью сервера TGS системы Kerberos.

Компоненты клиента

в системе SESAME имеется три клиентских компонента защиты. Во-первых, для

конечного пользователя SESAME предоставляет программу для входа в систему,

которая называется

спонсор пользователя {user

sponsor).

Эта программа позволя-

ет пользователю входить в систему, выходить из нее и изменять роли. Она вы-

полняется как отдельное приложение и предполагает, что пользователь уже рабо-

тает в локальной операционной системе. При входе пользователь должен ввести

пароль, по которому будет создан общий секретный ключ, используемый для свя-

зи с сервером защиты домена. Эта процедура входа соответствует аналогичной

процедуре системы Kerberos. С другой стороны, пользователь может иницииро-

вать строгий вход, в этом случае будет взят и использован, как описано выше, ло-

кально хранящийся закрытый ключ пользователя.

В зависимости от той роли, с которой пользователь подсоединился к системе,

он получает определенные стандартные привилегии, позднее, после аутентифи-

кации, передаваемые в форму РАС. Также соответствующие привилегии можно

запросить во время соединения.

Клиент доступа к аутентификации и привилегиям {The Authentication and

Piivilege Access

Client,

АРА Client)

—

это не что иное, как библиотека, содержащая

8.6. Пример

—

SESAME 523

простые процедуры, которые предоставляют пользователю интерфейс, а клиент-

ским приложениям

—

доступ к серверу защиты домена. Отметим, что эта биб-

лиотека при необходимости поддерживает также аутентификацию клиентских

приложений.

Третий компонент — это система управления

контекстом

защиты {Secure

Association

Context

Management,

SACM). Этот компонент отвечает за инициали-

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

няющимся на сервере приложением. Так, например, SACM, как и РАС, может

локально сохранять сеансовые ключи, полученные при входе пользователя в сис-

тему и пр. Таким образом, SACM позволяет клиентским приложениям совмест-

но использовать любую информацию по защите, необходимую для связи с сер-

верными приложениями.

Функциональность SACM традиционно поддерживается многими системами

защиты, в том числе и SESAME, и может быть реализована в разных системах

по-разному. Поэтому вместо того, чтобы поддерживать специальный интерфейс,

SACM реализует стандартный

обобщенный интерфейс программ службы защиты

{Generic

Security Service Application

Program

Interface, OSS-API), определенный

[267].

Компоненты сервера

в последнюю очередь среди групп компонентов мы рассмотрим компоненты,

работающие на стороне сервера. Подобно компонентам клиента, серверные при-

ложения также имеют свою систему SACM, с помощью которой они хранят ин-

формацию по защите, необходимую для связи с клиентами и другими приложе-

ниями.

SACM сервера отвечает за передачу в

систему проверки

РАС (РАС

Validation

Facility,

PVF) входящей информации, связанной с защитой. PVF извлекает из

входящих запросов всю необходимую информацию и проверяет ее. Так, напри-

мер,

она может расшифровать сообщение и извлечь из него сеансовый ключ или

после проверки подписи сертификата РАС извлечь из него права доступа. Или,

например, после того как система PVF идентифицирует пользователя, она мо-

жет передать информацию обратно в систему SACM, которая, в свою очередь,

передаст клиенту сообщение для аутентификации сервера.

Система PVF может быть размещена на одном сервере с другими приложе-

ниями или на отдельной доверенной машине, чтобы работать в интересах мно-

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

ром PVF и приложениями была защищена с обязательной аутентификацией

сторон и поддержанием конфиденциальности.

8.6.2. Сертификаты атрибутов привилегий

SESAME осуществляет не только аутентификацию клиентов и серверов, но и обес-

печивает авторизацию. Для этих целей используются сертификаты атрибутов,

которые, как уже говорилось ранее, выдаются сервером PAS. Чтобы получить

524 Глава 8. Защита

представление о том, как выглядят сертификаты атрибутов, рассмотрим РАС

системы SESAME детальнее.

Каждый сертификат РАС содержит несколько полей (табл. 8.2). Первые два

поля идентифицируют место, откуда передан сертификат. Имя сервера PAS мо-

жет определяться именем домена. Далее в РАС включен уникальный серийный

номер, который может быть использован для проверки.

Таблица 8.2. Структура сертификата атрибутов привилегий системы SESAME

Поле

Описание

Домен вызова (Issuer domain)

Идентификатор вызова

(Issuer identity)

Серийный номер (Serial number)

Время создания (Creation time)

Срок годности (Validity)

Периоды времени (Time periods)

Идентификатор алгоритма

(Algorithm ID)

Значение подписи (Signature value)

Привилегии (Privileges)

Информация о сертификате

(Certificate information)

Прочее (Miscellaneous)

Методы защиты

Название защищенного домена, из которого

передан вызов

Название PAS домена, из которого передан вызов

Уникальный номер данного сертификата РАС,

созданный сервером PAS

Время создания РАС по UTC

Интервал времени, в течение которого данный

сертификат РАС считается действительным

Дополнительные периоды времени, вне которых

сертификат РАС считается устаревшим

Идентификатор алгоритма, используемого

для подписи этого сертификата РАС

Подпись сертификата РАС

Список пар (атрибут, значение), описывающих

привилегии

Дополнительная информация, используемая

системой PVF

В настоящее время используется исключительно

для аудита

Поля для контроля использования

сертификата РАС

Следующие три поля относятся к сроку жизни сертификата. Значение време-

ни создания РАС по UTC хранится в отдельном поле. Это время, определяемое

сервером PAS, создавшим РАС. Кроме того, сохраняется время начала и конца

периода годности РАС. Возможно, РАС можно использовать в течение несколь-

ких временных отрезков. Это поле РАС может не использоваться. Временные

отрезки определяются в других полях.

Существует несколько способов подписать РАС. Конкретный метод определя-

ется специфическим для SESAME идентификатором алгоритма. Сама подпись

сохраняется в другом поле. Вместе с идентификатором алгоритма годность РАС

может быть впоследствии проверена получателем.

Поле привилегий содержит список пар (атрибут, значение), определяющих

права доступа, полученные владельцем РАС. Каждая привилегия ассоциирована

с набором полномочий. По определению эти полномочия относятся к домену за-

щиты, который вызвал РАС, в частности домен, в котором расположен сервер

8.7. Пример — электронные платежные системы 525

PAS,

создавший этот сертификат РАС. Однако можно также ассоциировать с при-

вилегией другой защищенный домен.

При необходимости можно предоставить дополнительную информацию, ко-

торая поможет принимающей системе PVF подтвердить подпись РАС. В частно-

сти,

в поле информации о сертификате может храниться сертификат, содержа-

щий открытый ключ PAS, которым был подписан сертификат РАС. И наконец,

имеется поле для дополнительной информации, используемое в настоящее вре-

мя только с целью аудита.

Сертификат атрибута может быть, а может и не быть делегируемым. В любом

случае можно определить, для какой цели (делегирование или использование на

месте) пригоден данный сертификат РАС. Эта информация хранится в отдель-

ном поле методов защиты РАС.

8.7. Пример

—

электронные платежные

системы

Ранее мы в основном рассматривали вопросы защиты традиционных распреде-

ленных систем

—

клиент и сервер создавали защищенный канал связи, после чего

клиент обращался к службам сервера. В основном вся защита ограничивалась

двухсторонним взаимодействием.

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

перестало сводиться к взаимодействию клиента с сервером. Мы видим, в частно-

сти,

что по мере распространения Интернета распределенные системы находят

применение в различных типах приложений, связанных с электронной коммер-

цией. Другими словами, люди покупают или продают через Интернет. В этом раз-

деле мы кратко рассмотрим важнейший аспект электронной коммерции, а имен-

но,

вопрос о том, как происходит оплата товаров. Мы покажем, что электронные

платежные системы основаны на методиках, разработанных для распределенных

систем, особенно в части их надежности и защиты. Описания электронных пла-

тежных систем можно найти в [19, 350].

8.7.1.

Электронные платежные системы

Оплата всегда предполагает наличие двух участников, продавца и покупателя.

большинстве случаев в процесс вовлекаются также один или два банка. Так

или иначе, покупатель должен быть уверен, что продавец получит свои деньги.

Это следует из того, что мы не можем рассчитывать на доставку товаров, за кото-

рые не заплачено.

Существует несколько способов организации платежных систем. Наиболее час-

то в реальной жизни используются наличные, чеки и кредитные карты. Соответ-

ствующие три структуры представлены на рис. 8.40. В системе на базе наличных

денег покупатели должны получить в своем банке наличные деньги, которые за-

тем передаются продавцу в обмен на товары (рис. 8.40, а). Продавцы впоследст-

526 Глава 8. Защита

ВИИ

могут использовать эти деньги, чтобы заплатить кому-нибудь еще или поло-

жить их на счет в своем собственном банке.

Банк

плательщика

Снятие

со счета

Банк

получателя

Плательщик

Оплата

Счет

в банке

Получатель

Банк

плательщика

Чек

Расчет

Банк

получателя

Плательщик

Передача

платежного

требования

Оплата

Банк

плательщика

Получение

денег

по чеку

Кредитная

карта

Получатель

Расчет

Банк

получателя

Плательщик

Передача

платежного

требования

Оплата

Предписание

Получатель

Рис.

8.40, Платежные системы на основе прямых платежей между

покупателем

продавцом.

Оплата

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

Другой подход применяется в системе на основе чеков, показанной на

рис.

8.40, б.

В этом случае покупатели имеют подписанные документы своего банка в виде

чеков, дающие право каждому, представившему эти чеки в указанный банк, на

перевод денег со счета покупателя. На практике банки покупателя и продавца

после предъявления продавцом чека в CBOPI банк сами производят взаимные рас-

четы.

Третий вариант, очень похожий на метод с использованием чека, основан на

кредитных картах (рис. 8.40, в). Для оплаты в системе с кредитными картами по-

купатель требует от банка перевода денег на счет продавца, предоставляя про-

давцу кредитную карту и удостоверяя считывание кредитной карты. Реальное

перечисление денег производится, когда продавец представляет результат счи-

тывания в свой собственный банк, который связывается с банком покупателя.

Существуют также и другие формы оплаты. Так, например, часто можно за-

платить за товар, перечислив деньги из банка покупателя в банк продавца аван-

сом. Получив информацию о перечислении денег на свой счет, продавец осуще-

ствляет доставку товаров (рис. 8.41, а). Эта схема платежа обычно используется

в том случае, если компания-продавец не знает покупателя и не хочет постав-

лять дорогой продукт до получения денег.

При использовании авизо, как показано на рис. 8.41, б, покупатель разрешает

продавцу предписать банку покупателя списывать определенные суммы с его сче-

8.7. Пример — электронные платежные системы 527

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

платежей

—

членских взносов или ежемесячных платежей за газ и электричество.

Банк

плательщика

Платежное

поручение

Платеж

Банк

получателя

Подтверждение

Плательщик

Банк

плательщика

3 Подтверждение

Получатель

Платеж

Банк

получателя

Плательщик

Передача

авизо

Авторизация

Платежное

поручение

Получатель

Рис. 8.41. Платежные системы на базе переводов денег из банка

банк.

Платеж по платежному поручению (а). Платеж по авизо (б)

Эти модели оплаты используются уже длительное время и большинство из

нас хорошо знакомы как минимум с некоторыми из них. В традиционном случае

(см.

рис. 8.40) модели требуют для произведения оплаты определенного физиче-

ского взаимодействия покупателя и продавца. Если подобный контакт невозмо-

жен или неудобен, могут использоваться другие модели (см. рис. 8.41). Однако

по мере того, как люди начали все активнее общаться друг с другом через такие

системы, как Интернет, использовать традиционные модели оплаты стало затруд-

нительно или вообпхе невозможно, поскольку покупателям и продавцам больше

не нужно встречаться.

Таким образом, мы началр! испытывать необходимость в специальных реше-

ниях для систем электронных платежей, которые соответствуют моделям оплаты

наличными, чеками или кредитными картами, но не требуют физического взаи-

модействия покупателя и продавца. Ниже мы рассмотрим два примера подоб-

ных систем, обсудив сперва требования по защите к электронным платежным

системам. Детальную информацию по защите электронных платежных систем

можно найти в

[415].

8.7.2. Защита в электронных платежных

системах

Должно быть понятно, что защита играет в электронных платежных системах

важную роль. Никому не понравится неавторизованный доступ к его банковско-

му счету, и никто не обрадуется продавцу, обвиняющему вас в неуплате. Это по-

зволяет нам утверждать, что защита в платежных системах играет значительно

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

Общие требования

Давайте рассмотрим для начала некоторые из наиболее очевидных требований

к защите моделей платежей, представленных на рис. 8.40. В системах на основе

528 Глава 8. Защита

наличных денег наиболее широко распространены

автоматические кассовые

ма-

шины {Automatic

Teller

Machines,

ATM), или банкоматы, которые работают в кон-

такте с одной из банковских баз данных. Когда Алиса хочет получить деньги

в своем банке, она должна сначала аутентифицировать себя. Она может исполь-

зовать специальный маркер в форме карты с магнитной полосой или чипом. Эта

карта, считываемая банкоматом, защищена

персональным идентификационным

номером {Personal

Identification Number

PIN). Алиса должна набрать свой номер

PIN, после чего ATM связывается с банком. Если аутентификация оказалась ус-

пешной, Алисе разрешается получить определенную сумму денег. Дополнитель-

ную информацию по банкоматам и PIN можно найти в

[119].

Существует и другой подход. Алиса может, не прибегая к помощи банкомата,

использовать для перевода денег со своего счета домашний персональный ком-

пьютер. В любом случае, если у Алисы есть деньги, она может заплатить тем или

иным способом. Один из способов, применяемых в электронных системах,

—

ис-

пользование смарт-карты, которая может хранить

цифровые деньги {digital

money),

существующие в форме битов. С другой стороны, Алиса может указать, что пред-

почитает хранить свои цифровые деньги локально, на собственном жестком диске.

Использование цифровых денег в схемах, разработанных для наличных, требу-

ет надежной защиты от мошенничества. В частности, нужно предотвратить воз-

можность использования цифровых денег более одного раза или возможность

изготовления фальшивых денег. Другими словами, мы явно нуждаемся в меха-

низме обеспечения целостности.

Когда Алиса использует свои цифровые деньги, чтобы заплатить Бобу, Боб

должен быть в состоянии проверить подлинность денег. Цифровые деньги счи-

таются подлинными, если Боб может пойти в свой банк и положить их на счет.

банк Боба хочет быть уверен, что эти деньги «реальны» и

HPI

Боб, ни Алиса ни-

чего с ними «не накрутили». В некоторых случаях это означает, что банк Боба

должен будет связаться с банком, который изначально выпустил эти деньги. За-

тем последует традиционная процедура аутентификации, в ходе которой банк

Боба будет аутентифицировать банк Алисы.

Теперь обсудим систему, основанную на использовании чеков или кредитных

карт. Снова нетрудно увидеть, что необходимым условием прохождения платежа

являются стандартные требования аутентификации и авторизации чека или кре-

дитной карты, которые Алиса выдала или предъявила. Когда Боб принимает опла-

ту электронным чеком, он хочет, чтобы чек был защищен от подделок. Его банк

также хочет быть уверен, что в чек не вносились исправления.

Однако можно указать на необходимость более строгих требований к защите

от отказа в оплате, чем в случае систем на основе наличных денег. Так, например,

стандартный способ покупки товаров через Интернет

—

посылка заказа с указа-

нием номера кредитной карты. Хотя номер кредитной карты часто шифруется до

пересылки его продавцу, он не является эквивалентом подписи на чеке или дан-

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

но легко (теоретически) отрицать сам факт заказа. Защита от отказа в оплате мо-

жет быть реализована, например, путем требования к покупателю передавать

в своей части транзакции цифровую подпись.

8.7. Пример — электронные платежные системы 529

В связи с возможностью отказа от оплаты мы особенно жестко требуем, что-

бы транзакция происходила атомарно

—

это гарантирует, что она либо будет про-

ведена полностью, либо не произойдет вообще. Это требование вытекает из того

факта, что после того, как Алиса заплатит магазину Боба, следует защищать не

только Боба от отказа Алисы признать факт посылки заказа. Алиса также долж-

на быть защищена от отказа Боба признать факт оплаты. Если система подтвер-

дит Алисе, что оплата была произведена, это должно означать, что Боб получил

деньги и не сможет впоследствии отказаться от этого факта.

Хотя мы сосредоточили свое внимание на вопросах защиты, следует пони-

мать,

что электронные платежные системы предполагают также и требование на-

дежности доступа. В частности, система в целом должна быть легкодоступной

и иметь высокую степень надежности.

Закрытость

Хотя запросы к требованиям защиты в электронных платежных системах выше,

чем в традиционных распределенных системах, они в принципе могут быть реа-

лизованы с использованием описанных выше технологий. Однако существует од-

на проблема, которая заслуживает особого внимания и нередко выделяет элек-

тронные платежи из общего ряда приложений

—

это закрытость.

Просто защитить платеж от любопытных глаз относительно просто

—

доста-

точно воспользоваться стандартными методами шифрования. Трудно обеспечить

анонимность. В стандартных системах платежей анонимный платеж несложен:

Алиса просто передает Бобу мешок денег в обмен на купленные ей товары. Ни-

каких вопросов. Алисе обычно нет необходимости знать, кто такой Боб, а Боба

абсолютно не интересует, кто такая Алиса. Единственное, что имеет значение

—

товар и деньги.

Дело усложняется, если Алиса и Боб используют электронную платежную

систему. Одна из первых вещей, которую следует рассмотреть,

—

это защита мик-

роданных. Микродаппые (microdata)

—

это малые элементы данных, которыми

сопровождается каждая транзакция. Если собрать их вместе, они способны от-

крыть одну из сторон, вовлеченных в эту транзакцию. Рассмотрим, например,

анонимный платеж, в ходе которого записывается имя хоста, инициировавшего

этот платеж, и время оплаты. Сравнение этой информации с записями о входах

в систему позволит сразу же определить личность покупателя. Другая информа-

ция, доступ к которой обычно можно получить таким образом,

—

это определен-

ные значения атрибутов, которые постепенно приводят нас к получению полно-

го профиля интересов этого человека.

На практике защита системы от нарушения закрытости состоит в том, чтобы

сделать покупателя анонимным. Делать анонимным продавца обычно нет необ-

ходимости. Анонимность в данном слз^^ае означает невозможность аутентифика-

ции покупателя в ходе или по окончании транзакции. Иногда может быть не-

обходимо опознать личность, например, в случае дискуссии. Такая ситуация

называется условной

анонимностью (conditional

anonymity).

Имеется и другой подход, состоящий в сокрытии личности покупателя под

псевдонимом. Псевдоним

—

это альтернативное имя, используемое в ходе трап-

530 Глава 8. Защита

закции или серии транзакций. Псевдоним обладает специфическим свойством:

пользователя фактически можно идентифицировать по псевдониму, но узнать

истинные данные пользователя по псевдониму покупателя в принципе невоз-

можно. Обычно псевдонимы используются для реализации условной анонимно-

сти.

Чтобы сообразить, как скрыть от платежной системы лишние данные, рас-

смотрим сначала систему на основе традиционных методов платежа [81]. Каж-

дый столбец на рис. 8.42 содержит атрибут транзакции, который следовало бы

скрыть. Мы выделили пять атрибутов: личность продавца, личность покупателя,

дата транзакции, уплаченная сумма и информация об оплачиваемом предмете.

В каждой строке указана одна из сторон, вовлеченных в транзакцию. Мы выде-

ляем три стороны: продавец, покупатель и банк. Кроме того, представим себе

идеально расположившегося наблюдателя (известного как Чак), который просто

отслеживает происходящие транзакции. Так, например, в случае покупки това-

ров в магазине Чак может быть следующим человеком в очереди.

Информация

Продавец Покупа- Дата Сумма Товар

Сторона

Продавец Полностью Частично Полностью Полностью Полностью

Покупа-

тель

Банк

Наблюда-

тель

Полностью

Нет

Полностью

Полность

Нет

Частично

Полностью Полностью Полностью Полностью

Нет Нет Нет

Полностью Полностью Полностью

Рис. 8.42. Сокрытие информации в традиционных платежных системах

Для каждого участника транзакции определяется элемент, показывающий,

насколько хорошо он будет знать конкретный атрибут. Так, например, покупате-

лю в платежной системе на основе наличных видны продавец, дата транзакции

и сумма, а также купленный товар. Однако продавец, как обычно в случае покуп-

ки товара в магазине, не слишком нуждается в знании личности покупателя.

Интересно отметить, что банк на самом деле не знает ничего, хотя у него и мо-

гут возникнуть некоторые соображения о сумме платежа в результате простого

наблюдения за тем, сколько денег продавец в результате транзакции положит на

счет. Другими словами, саму транзакцию записать невозможно, а это делает по-

купателя полностью анонимным. Продавцу в случае особо крупных транзакций

анонимным быть ни к чему. Большинство банков по закону обязаны делать за-

писи о транзакциях, в ходе которых продавец кладет деньги в банк.

Теперь рассмотрим традиционные транзакции с кредитными картами? Что

касается сокрытия информации, несложно заметить, что абсолютно все атрибуты,

перечисленные на рис. 8.42, будут видны всем участникам. Однако наблюдатель

испытает некоторые затруднения при аутентификации покупателя, и вдобавок

банк никогда не получит информации о том, что именно приобретено покупате-

лем. Это дает нам таблицу, представленную на рис. 8.43 [81].