Електронни проверки

Тези блокове могат да бъдат вложени и да имат свои собствени електронни цифрови подписи (EDS). Първоначално проверката съдържа минимум информация, но тъй като проверката се прехвърля от един участник на друг, е възможно да се добавят или отделят някои блокове данни. Например, когато банката издава чек на платеца, тя може да съдържа само информация за личната сметка на платеца, сертификат и подписа на банката. Когато извършва плащане, платецът попълва полетата за размера на плащането и действието, което трябва да бъде извършено, а също така поставя своя подпис. След получаване на чека получателят може да се подпише, като по този начин потвърждава получаването на чека. Когато получателят изпрати чека на своята банка, последният може също да добави блок с информация за себе си и сметката на получателя, като същевременно премахва част от информацията, която не представлява интерес за банката на платеца, например потвърждение за получаване на чека от получателят. Така по време на жизнения цикъл електронната проверка променя размера си няколко пъти. Първоначално празният чек има размер 4762 байта, след добавяне на блокове с информация за вида на операцията и стойността на сумата, размерът му се увеличава до 7052 байта, чек с паричен превод и всички потвърждения има размер 14 433 байта. Пример за електронна проверка на език FSML е показан на фиг. 6.2.

електронни

6.3. Обработка на електронни чекове

Схемата за обработка на електронни разписки, показана на фиг. 6.3, много подобно на обработката на хартиен чек.

интуит

Платецът C отправя искане за издаване на електронен чек на своята банка. Банката отговаря на това искане чрез издаване на чеков формуляр. Когато извършва плащане, платецът попълва чека, като добавя съответните полета и препраща подписания чек на получателя М. Той от своя страна изпраща чека на своята банка. Банката на получателя потвърждава чека и го препраща чрез защитена банкова мрежа към банката на платеца, която дебитира средства от съответната сметка.

Нека разгледаме горния процес по-подробно, като използваме примера за взаимодействието на субектите на платежната транзакция в системата NetCheque [3GPP TR 21.905: Речник за спецификации на 3GPP.]. В този случай сървърът Kerberos [EMV ICC Specification for Payment Systems.] Действа като шлюз за плащане, предоставяйки на участниците във взаимодействието сесионни ключове за взаимно удостоверяване един на друг. Системата NetCheque използва три сесийни ключа:

  • - ключ за организиране на сигурно взаимодействие между платеца и неговата банка;
  • - ключ за организиране на сигурно взаимодействие между получателя и неговата банка;
  • - ключ за организиране на сигурно взаимодействие между банката на получателя и банката на платеца.

Когато извършва платежна транзакция, платецът съставя чек (Проверете) във FSML, след което се обръща към сървъра Kerberos с искане за получаване на билет, необходим за взаимно удостоверяване на платеца и неговата банка и организиране на защитен канал за предаване на данни между тях. Билетът за сесия е идентификатор S на сървъра Kerberos и идентификаторите на платеца, неговата банка и сесиен ключ за взаимодействие между тях, кодирани с помощта на секретния ключ за взаимодействие между банката на платеца и сървъра Kerberos:

За взаимно удостоверяване на себе си и на банката си платецът изчислява стойността