Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012
.pdf572 |
Глава 32. Общая характеристика ЮТР-протокола |
пользованием физических средств доставки. Второе предназначение: обеспечить покупателя дополнительной информацией о предстоя щей доставке приобретенных товаров, отражающей детали их транс портировки (например, номер авиарейса или маршрут и порт при бытия морского судна и другое). Компоненты, входящие в данную процедуру могут также подписываться в целях оказания помощи по купателю при возникновении проблем и конфликтов при физиче ской доставке товаров. Данная процедура представлена на рис. 32.7.
Торговая процедура «доставка товаров или услуг» использует следующие информационные компоненты (в составе ЮТР-сообще- ний), которыми обмениваются между собой покупатель, продавец и система доставки:
о«Status» (состояние) - используется для указания системе дос тавки, что предшествующая торговая процедура (например,
«offer exchange» или «payment exchange») успешно завершена. Если этот компонент направляет система доставки, то он ука зывает на завершение торговой процедуры «delivery exchange»;
•«Organization» (организация) - содержит точные данные об участниках торговой сделки (продавец, система доставки и компания по доставке товаров, которая будет непосредственно получать приобретенные товары или услуги):
-компания по доставке товаров указывает, где она будет принимать приобретенные товары или услуги;
-система доставки требует того, чтобы она как участник тор говой сделки могла проверять корректность выбора систе мы платежей с целью правильного осуществления после дующей доставки товаров или услуг;
-продавец, как участник торговой сделки, требует того, что бы система доставки указала тип доставки, который опреде лил продавец;
о«Order» (заказ) - содержит перечень товаров или услуг, кото рые проданы покупателю и будут ему доставляться;
в«Delivery» (доставка) - содержит информацию о том, как будет осуществляться доставка, например, по почте или с использо ванием ЭП;
о«Offer Response Signature» (ЭЦП ответа на предложение) - (не обязателен) если он имеет место, то он представляет собой ЭЦП, вычисленную по всем предшествующим компонентам для обеспечения их целостности;
о«Payment Receipt Signature» (ЭЦП приёма платежа) - (не обяза телен) обеспечивает защиту платежа от подделки путем вы числения ЭЦП по компонентам «Payment Receipt» и «Offer Re sponse Signature». Этот компонент используется системой дос тавки для проверки данных авторизации от покупателя;
Раздел VI. |
573 |
в«Delivery Note» (дополнительная информация о предстоящей доставке приобретенных товаров) - содержит информацию для покупателя о способе реализации физической доставки или, в противном случае, об имеющихся в наличии «элек тронных товаров». ПО покупателя не воспринимает инфор мацию о физической доставке товаров или услуг, но оно должно иметь возможность выводить эту информацию на дисплей (и в период доставки, и позже, если покупатель вы брал торговую операцию, для которой данная система достав ки входит в перечень торговых сделок);
в«Delivery Response Signature» (ЭЦП ответа на запрос доставки) - (не обязателен) если он представлен, то обеспечивает защиту от подделки результатов торговой процедуры «delivery exchange» путем вычисления ЭЦП по следующим компонентам: «Delivery Note» и один из двух или «Offer Response Signature», или «Pay ment Response Signature» (какой был получен системой доставки).
Итогом торговой процедуры «delivery exchange» (при прочих положительных условиях) является электронная квитанция о дос тавке, сформированная и подписанная системой доставки и опре деляющая порядок и условия доставки покупателю приобретенных товаров или услуг.
Процедура аутентификации («authentication exchange»). На значение: возможность одной организации (например, финансового института) проверить подлинность другой организации (например, покупателя) перед началом (или в период) электронной торговой операции.
В этой процедуре участвуют:
осубъект аутентификации (аутентифицирующий) - тот, кто за прашивает процедуру аутентификации;
ообъект аутентификации (аутентифицируемый) - тот, кто про ходит процедуру аутентификации.
На рис. 32.8 представлена процедура аутентификации. В про
цедуре аутентификации используются следующие торговые ком поненты (в составе IOTP-сообщений), которыми обмениваются меж ду собой объект и субъект аутентификации:
о«Authentication Request» (запрос аутентификации) - запраши вает процедуру аутентификации, с указанием алгоритма ау тентификации, и дополнительные данные, которые могут быть использованы;
©«Trading Role Information Request» (запрос дополнительных данных об участнике торговой сделки) - требует дополни тельной уточняющей информации об объекте аутентифика ции, например, адрес получателя товара;
0«Authentication Response» (ответ на запрос аутентификации) - содержит ответные данные, сформированные получателем
574 |
Глава 32. Общая характеристика ЮТР-протокола |
компонента «Authentication Request» и необходимые для при нятия решения субъектом аутентификации;
•«Organization» (организация) - содержит дополнительную уточняющую информацию об объекте аутентификации (в от вет на компонент «Trading Role Information Request»);
•«Status» (состояние) - содержит результаты процедуры аутен тификации, проведенной субъектом аутентификации на ос нове данных, которые содержатся в компоненте «Authentica tion Response».
! Итерации j |
Объект |
аутентификации |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
процедуры аутентификации |
Х |
а |
р |
а |
к |
т |
е |
р |
и |
с |
т и |
к |
а |
|
|
|||||
|
|
|
|
|
О б ъ е к т ау тстггп ф и к а ц н н (н а п р и м е р , |
п о к у п а т е л ь ) в ы п о л н я е т д е й с т |
|
|||||||||||||
|
|
|
|
|
в и е (н а п р и м е р , |
п \ гем |
н а ж а ти я |
к н о п к и |
н а НТМТ .-с т р а н и ц е ), ко т р о е |
|
||||||||||
|
1 |
|
|
------------ [ ) |
за п р а ш п в а е 1 н е о б х о д и м о е it п р о х о ж д е н и я п р о ц е д у р ы а у т е н ш ф и - |
|
||||||||||||||
|
|
|
к ац и и о б ъ ек т о м . |
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
П е р е д а в а е м ы е д а н н ы е и н ф о р м а ц и я о н е о б х о д и м о й » п р о х о ж д е н и я |
|
||||||||||||||
|
|
|
|
|
!п р о ц е д у р ы ау те н т и ф и к а ц и и о б ъ е к т о м |
в I O T P -п р о т о к о л о н е р а с |
|
|||||||||||||
|
|
|
|
|
с м а т р и в а е т с я |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
С у б ъ е к т а у т е н т и ф и к а ц и и ф о р м и р у е т “ З а п р о с а у т е н т и ф и к а ц и и ", |
|
||||||||||||||
|
|
|
|
|
к о т о р ы й в к л ю ч а е т п е р е ч е н ь з а п р а п и т а е м ы х д а н н ы х и п ер еч ен ь |
|
||||||||||||||
|
|
|
|
............м а н и ю |
д о п у с т и м ы х |
а л го р и т м о в |
а у т е н т и ф и к а ц и и , и 'и л и -запрос |
на и н ф о р - |
|
|||||||||||
; |
2 |
< |
= |
о б у ч а ст н и к е то р го в о й с д е л к и |
|
о б ь е к ч е а у те н т и ф и к а ц и и , а |
1 |
|||||||||||||
|
' и н о м н ап р авля ет о б ь с к т у а у т е ш и ф н к а ш ш |
|
|
|
|
|||||||||||||||
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
2 ‘З а п р о с а у те н т и ф и к а ц и и ” ( “ A U T H E N T I C A T I O N R E Q U E S T " ) |
j |
||||||||||||||
|
|
|
|
|
К о м п о н е н т ы |
“ A u th e n tic a tio n |
R e q u e s t" , “ T ra d in g |
R o le |
In fo rm a tio n |
|
||||||||||
|
|
|
|
|
R e q u e s t" . |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
О б ъ е к т а } т е 1г ш ф и к а ш ш п р о в е р я е т н а л и ч и е п о д п и с и и с а м > п о д |
|
||||||||||||||
|
|
|
|
|
п и с ь (н с о б я за т е л ь н о ), с в я за н н у ю с |
к о м п о н е н т о м “A u th e n tic a tio n |
|
|||||||||||||
|
|
|
|
|
R e q u e s t \ -д н е м и с п о л ь зу я о п р е д е л е н н ы й а л г о р т м а у те н т и ф и к а ц и и |
|
||||||||||||||
|
3. |
|
|
|
.ф о р м и р у е т “ О т ве т |
на з а п р о с а у т е н т и ф и к а ц и и ", к о то р ы е |
нап р авляет |
|
||||||||||||
1 |
|
|
________о б р а ш о с у б ъ е к т у |
а у т е н т и ф и к а ц и и , а т а к ж е д о п о л н и т е л ь н у ю и н - |
|
|
||||||||||||||
|
|
|
|
^ ю р м а ц н ю о с е б е к а к у ч а с т н и к е т о р го в о й с д е л к и . |
|
|
|
|||||||||||||
|
|
|
|
|
.“ О т вет |
иа за п р о с а у т е н т и ф и к а ц и и " ( “A U T H E N T I C A T I O N R E |
|
|||||||||||||
|
|
|
|
|
S P O N S E " ) . |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
К о м п о и е ш ы |
“ A u th e n tic a tio n |
R e s p o n s e " , “O r g a n iz a tio n (s )" . |
|
||||||||||||
|
|
|
|
|
С у б ъ е к т п р о в е р я е т п о л у ч е н н ы й “ О т в е т н а за п р о с а у т е 1ггп ф н к ац н н ” |
|
||||||||||||||
|
|
|
|
|
н а к о р р е к т н о ст ь в с е х п р е д с т а в л е н н ы х д а н н ы х , у б е ж д а е т с я в п о д - |
|
||||||||||||||
! |
|
|
|
----------------, |
л ш ш о о г и о б ъ е к т а |
а у т е и ш ф н к а ц п н . н з а т е м |
«}м р м п р у ст к о м п о н ен т |
|
||||||||||||
4 . |
< S = j |
“ S ta tu s " и н а п р а вл я е т е г о о б ъ е к т у . |
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
“ Р е зу л ь т а т а у т е н т и ф и к а ц и и " ( “ A U T H E N T I C A T I O N S T A T U S " ) . |
|
||||||||||||||
|
|
|
|
|
.К о м п р н е т . “ S ta tu s " . |
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
О б ь е к т а у те н т и ф и к а ц и и п р о в е р я е т -(н е о б я за т е л ь н о ) р е зу л ь та т ы е ю |
|
||||||||||||||
■ |
5 |
|
|
|
а у те н т и ф и к а ц и и , у к а за н н ы е в к о м п о н е н т е “ S ta tu s " , н О Ц П , св я за н - | |
|||||||||||||||
|
|
|
тту ю с н и м , п вы п о л н я ет |
с о о т в е т а в у ю щ п е д е й с т в и я |
ш и |
п р е к р а т и - |
j |
|||||||||||||
|
|
|
|
|
||||||||||||||||
е г т о р г о в у ю о п е р а ц и ю .
Рис. 32.8. Характеристика процедуры «аутентификация»
Итогом процедуры «authentication exchange» (при прочих по ложительных условиях) является согласие обеих сторон на даль нейшее проведение торговой операции (в противном случае - по следует отказ одной из сторон от дальнейшего участия в торговой операции и, следовательно, прекращение последней).
Глава 33. Общая характеристика PAPI-интерфейса
IOTP-протокол определяет логическую (формат XML-сообщений и правила кодирования) и процедурную характеристики информа ционного обмена (электронного документооборота) при осуществ лении электронных торговых сделок, и на этой основе интегрирует существующие платежные системы (протоколы и алгоритмы) в еди ную универсальную систему. В этой связи возникает проблема кор ректного взаимодействия базового IOTP-протокола с несколькими вышележащими протоколами специализированных платежных сис тем (рис. 33.1). Эта проблема решается с помощью специализирован ного прикладного программного интерфейса для платежных систем - PAPI (Payment Application Programmers Interface).
Протокол 1-ой |
Протокол 2-ой |
Протокол 3-ей |
|
|
платежной |
платежной |
платежной |
Q О О |
|
системы |
системы |
системы |
|
|
— — |
Ч |
......4 К |
... |
4К |
|
ПРИ (ПАДКОЙ ИН' ЕРФЕЙСДЛЯ ПЛАТЕЖНЫХ CHCljEM j
>* |
># |
f' |
y# |
\ |
|
Подуровень IQTP прикладного (S-го) уровня
архитектуры INTERNET
Рис. 33.1. Прикладной интерфейс для платежных систем
В Internet-архитектуре платёжный PAPI-интерфейс располага ется между подуровнем IOTP-протокола прикладного (5-го) уровня архитектуры Internet (или просто подуровень IOTP-протокола) и прикладными программными модулями, образующими свой выше лежащий подуровень прикладного уровня Internet-архитектуры и реализующими определенные протоколы в интересах различных платежных организаций или ассоциаций. При этом PAPI-интерфейс позволяет корректно взаимодействовать не только двум субъектам в рамках одной платежной системы (ассоциации), но и субъекту одной платежной системы с субъектом другой системы электронных плате жей, т.е. различным программным модулям. Более того, PAPI-интер-
576 |
Глава 33. Общая характеристика РАРГинтерфейса |
фейс предоставляет возможность «безболезненного» проведения не обходимой модернизации программного обеспечения (ПО) и встраи вания нового прикладного ПО в программный модуль, реализующий ЮТР-протокол.
Такие PAPI-интерфейсы существуют в ПО покупателей, продав цов и платежных систем, которые соединяют программные модули ЮТР-протокола с программными компонентами платежных систем.
33.1. Структура PAPI
Совокупность ТСР/IP-протоколов, составляющих технологи ческую основу Internet-сети, представляет собой базовый сетевой транспортный способ и средство для представления и интерпрета ции данных, совершенствования прикладных служб и сетевой ин фраструктуры, обеспечения безопасности и ЭДО.
Однако наличие у участников электронных торговых сделок (Internet-магазины, системы управления платежами и доставкой то варов или услуг или современная электронная инфраструктура фи нансовых организаций) уже встроенного ПО со своими разнородны ми внутренними PAPI-интерфейсами ограничивает совместимость IOTP-протокола с программными модулями этих участников ЭК, что усложняет разработку международного стандарта PAPI-интерфейса для использования его в Internet. Однако некоторые из этих специ альных платежных прикладных интерфейсов могут быть стандарти зированы, что в свою очередь позволит обеспечить лучшие условия для интеграции ПО различных платежных систем на базе программ ного IOTP-модуля, причем без значительных изменений существую щей платежной информационно-телекоммуникационной инфра структуры и больших инвестиций в «эти изменения».
Типичные платежные системы (т.е. финансовые институты или небанковские организации), а также и продавцы требуют пол ностью совместимого ПО IOTP-протокола, которое бы «легко» встраивалось в их действующие финансовые инфраструктуры. Пла тежные системы могут даже потребовать применение аналогичных специализированных решений (для некоторых частных задач) в программном модуле IOTP-протокола (например, аналогичных криптомодулей, прикладных программных интерфейсов или ре шений по физической защите информации). Поэтому очевидна не обходимость в использовании специальных PAPI-интерфейсов для ЮТР-протокола.
Более того, покупатели требуют, чтобы их ПО имело внутрен ние программные модули, реализующие интерфейсы для
Раздел VI. |
577 |
ных систем. Они предпочитают адаптивность (так называемые са монастраивающиеся системы) при использовании различных пла тежных средств и способов в рамках одного торгового программно го модуля, который реализует режим работы, адекватный пользова тельскому интерфейсу. Существование «хорошо известного» ин терфейса позволяет разработчикам ПО различных платежных сис тем создавать такие дополнительные торговые модули для взаимо действия этих программных продуктов между собой через подуро вень IOTP-протокола (и Internet).
Очевидно, что программный модуль любого участника торго вый сделки IOTP-протокола состоит как минимум из двух базовых программных блоков (два подуровня прикладного уровня Internetархитектуры), а именно (см. рис. 33.1):
1)некоторый общесистемный компонент IOTP-протокола (собст венно ЮТР-протокол - программный модуль, реализующий ЮТР-протокол), так называемый подуровень ЮТР, который обеспечивает обслуживание электронных торговых сделок и общую структуру (логику и алгоритмы) ведения электронного бизнеса;
2)специальные «оконечные» системы участников электронного бизнеса (подуровень электронных платежных систем), реали зующие проведение специфических операций ЭК.
Чтобы не изменять сложившуюся архитектуру электронной
платежной инфраструктуры (при использовании Internet), про граммный модуль IOTP-протокола предусматривает дополнитель ный (третий) подуровень прикладного уровня, а именно:
вподуровень IOTP-протокола, на котором обрабатываются ос новные IOTP-сообщения и осуществляются процедуры элек тронных торговых операций и обеспечивается соединение че рез Internet-сеть;
оподуровень протоколов типовых (существующих) платежных систем (т.е. программные модули, реализующие эти платеж ные системы), на котором обрабатываются определенные ти пы электронных торговых операций и соответствующие им типы электронных платежных операций;
одополнительный (промежуточный) IOTP-подуровень (так на зываемый IOTP-мост), который соединяет два других (возмож но не совместимых) подуровня (программных модуля). (При мечание. Термин «мост» используется для обозначения аппа ратно-программного устройства (блока взаимодействия) ка нального (второго) уровня Internet-архитектуры. Это устройст-
580 |
Глава 33. Общая характеристика РАРГинтерфейса |
варов или услуг, условиями их доставки, способа платежа и стоимо сти покупки.)
Тем не менее, некоторые платежные схемы (протоколы): в ограничиваются односторонней аутентификацией;
опроводят процедуру авторизации в режиме «off-line» без како го-либо обращения к соответствующей организации, выдав шей покупателю платежное средство (КК, смарт-карту или другое средство);
оприменяют так называемый групповой режим при обработке платежного средства, поставленного в очередь на оплату при обретенных товаров или услуг;
вне делают различий между процедурами авторизации и по становки платежного средства в очередь на оплату;
оне имеют внутренних способов аннулирования платежей или применяют такие способы ограниченно.
Рассмотренная модель платежной схемы присуща не только типовым торговым операциям, но и широко используется при опла те электронных банковских чеков, размещении денег и их снятии со счета в финансовом учреждении, кредитно-дебетовых и валютных операциях и переводе денег.
33.3. Общие и специфические функции программного IOTP-модуля и ЮТР-моста
В широком смысле, IOTP-мост обрабатывает некоторую вход ную последовательность сообщений платежного протокола, которая поступает с IOTP-подуровня. Такая обработка включает:
•«разборку» сообщений;
®отображение этих сообщений в сообщения другого формата, в соответствии с требованиями ПО определенной платежной системы;
в «сборку» ответных сообщений на поступившие сообщения;
•отправку последовательности ответных сообщений платежно го протокола, которая, как правило, предназначается для «прозрачной» передачи IOTP-протоколом (ЮТР-подуровень) другому удаленному программному IOTP-модулю, взаимодей
ствующего участника электронной платежной операции. Обычно, этот процесс между двумя участниками продолжает
ся до тех пор, пока РAPI-интерфейс платежной системы «не подаст сигнал» об окончании платежной операции. При этом каждый без исключения программный компонент (модуль) системы может пре рвать такую операцию.