安全電子交易協議

決卡付款保障題，包括：保證息密，保證息傳輸，竊，收件密息；保證支付息完整，保證傳輸據完整收，途篡改；證商客戶，驗證共網路交易包括計構設置、計配備及職責權履計規、制制施容。合、效組織計，義，助提計息質量，執財紀律規；助提濟效益，優化資源配置。計組織必須合合規。講求效益，必須建完善控制制，必須強組織保證。

              .              ,           -.                 .        ,            .        ,             .       ,          .

     :  ,  ,    gateway (essentially a bank). The cardholder shares the order information with the merchant but not with the payment gateway. He shares the payment information with the bank but not with the merchant. A set dual signature accomplishes this partial sharing of information while allowing all parties to confirm that they are handling the same transaction. The method is simple: each party receives the hash of the withheld information. The cardholder signs the hashes of both the order information and the payment information. Each party can confirm that the hashes in their possession agrees with the hash signed by the cardholder. In addition, the cardholder and merchant compute equivalent hashes for the payment gateway to compare. He confirms their agreement on the details withheld from him.

All parties are protected. Merchants do not normally have access to credit card numbers. Moreover, the mere possession of credit card details does not enable a criminal to make a SET purchase; he needs the cardholder’s signature key and a secret number that the cardholder receives upon registration. The criminal would have better luck with traditional frauds, such as ordering by telephone. It is a pity that other features of SET (presumably demanded by merchants) weaken these properties. A merchant can be authorized to receive credit card numbers and has the option of accepting payments given a credit card number alone.

SET is a family of protocols. The five main ones are cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. There are many minor protocols, for example to handle errors. SET is enormously more complicated than SSL, which merely negotiates session keys between the cardholder’s and merchant’s Internet service providers. Because of this complexity, much of which is unnecessary, the protocol is hardly used. However, SET contains many features of interest:

The model is unusual. In the registration protocols, the initiator possesses no digital proof of identity. Instead, he authenticates himself by filing a registration form whose format is not specified. Authentication takes place outside the protocol, when the cardholder’s bank examines the completed form.

The dual signature is a novel construction. The partial sharing of information among three peers leads to unusual protocol goals.

SET uses several types of digital envelope. A digital envelope consists of two parts: one, encrypted using a public key, contains a fresh symmetric key K and identifying information; the other, encrypted using K, conveys the full message text. Digital envelopes keep public-key encryption to a minimum, but the many symmetric keys complicate the reasoning. Most verified protocols distribute just one or two secrets.

SET支付系統主要由持卡人（CardHolder）、商家（Merchant）、發卡行（Issuing Bank）、收單行（Acquiring Bank）、支付網關（Payment Gateway）、認證中心（Certificate Authority）等六個部分組成。對應地，基於SET協議的網上購物系統至少包括電子錢包軟體、商家軟體、支付網關軟體和簽發證書軟體。

1）消費者利用自己的PC機通過網際網路選定所要購買的物品，並在計算機上輸入訂貨單、訂貨單上需包括在線商店、購買物品名稱及數量、交貨時間及地點等相關信息。

2）通過電子商務伺服器與有關在線商店聯繫，在線商店作出應答，告訴消費者所填訂貨單的貨物單價、應付款數、交貨方式等信息是否準確，是否有變化。

3）消費者選擇付款方式，確認訂單簽發付款指令。此時SET開始介入。

4）在SET中，消費者必須對訂單和付款指令進行數字簽名，同時利用雙重簽名技術保證商家看不到消費者的帳號信息。

5）在線商店接受訂單后，向消費者所在銀行請求支付認可。信息通過支付網關到收單銀行，再到電子貨幣發行公司確認。批准交易后，返回確認信息給在線商店。

6）在線商店發送訂單確認信息給消費者。消費者端軟體可記錄交易日誌，以備將來查詢。

7）在線商店發送貨物或提供服務並通知收單銀行將錢從消費者的帳號轉移到商店帳號，或通知發卡銀行請求支付。在認證操作和支付操作中間一般會有一個時間間隔，例如，在每天的下班前請求銀行結一天的帳。

前兩步與SET無關，從第三步開始SET起作用，一直到第六步，在處理過程中通信協議、請求信息的格式、數據類型的定義等SET都有明確的規定。在操作的每一步，消費者、在線商店、支付網關都通過CA（認證中心）來驗證通信主體的身份，以確保通信的對方不是冒名頂替，所以，也可以簡單地認為SET規格充分發揮了認證中心的作用，以維護在任何開放網路上的電子商務參與者所提供信息的真實性和保密性。