Security Policies on the Internet: Electronic Payments and the iKP Protocols -- Ryan G. Lane
Security Policies on the Internet:
Electronic Payments and the iKP Protocols
Ryan G. Lane
Abstract:
Secure electronic payment systems over the Internet are necessary for the continued growth of electronic commerce. A practical, secure, and efficient protocol for electronic payments should be able to use the existing financial networks for credit card transactions and be able to be extended to other payment models. A payment system should also provide a high level of security with minimal use of cryptography to minimize computation time and increase efficiency. The iKP protocols (i-Key Protocol, where i is the number of parties with a public key pair) developed at IBM Research represent such a model and provide not only the protocol design, but the implementation and deployment of the system as well. The iKP protocols represent a starting point for eventual standards[3].
I. Introduction.
The rapid growth of the Internet and electronic commerce has created a dire need for secure electronic payments. Without a secure payment system, the future potential of electronic commerce is severely limited. There are various models for electronic payments which must be considered. Payment systems over the Internet can be modeled as cash-like, where money is taken away from the payer before purchases are made and is used for payments later, or bank-card-based, where an adjustment is made to the payer’s account at the time of the payment. Bank-card-based systems can be pay-now (Automatic Teller Machine cards) or pay-later (credit cards) and are also referred to as check-like systems, due to the fact that a ‘form’ is transmitted from the payer to the payee. Bank-card-based systems represent direct-payment systems in which a transaction requires interaction between the payer and the payee. There are also indirect-payment systems where the transaction is initiated by one party without the other party being involved, for example, electronic funds transfer. Payments may also be made offline meaning there is no third party involved and only the payer and payee participate in the transaction. Online payments include an authorization server to verify that a payer has the resources to satisfy the payment.
An early study conducted by the Bank of America involved transmitting Financial Electronic Data Interchange (FEDI) payment instructions over the Internet simply using Privacy Enhanced Mail (PEM) and Multipurpose Internet Mail Extensions (MIME). The FEDI transmissions were encrypted at a server, transmitted over the Internet in encrypted form via email, and decrypted at the security server of the receiver[5]. This simple model achieved a high degree of success and assisted in showing that the Internet could provide security and reliability for crucial transactions. Later payment models are generally more elegant and involve superior encryption and security standards.
The general security requirements for an electronic payment system include integrity, authorization, confidentiality, availability, and reliability[1]. Electronic payment systems should not prevent an honest payer from making a legitimate payment, but disallow unauthorized payments from dishonest payers or intruders. The exact security requirements for payment systems vary depending on the features implemented as well as the trust assumptions of the model.
The iKP protocols (i-Key Protocol, where i stands for the number of parties that possess a public key pair) are based on a direct, online, credit card/bank-card model (check-like system). The protocols are designed to be extendable to other models and are based on public key cryptography. The i in iKP refers to i =1, 2, or 3 (i-Key-Protocol), which signifies how many parties in the protocol maintain a public key pair. Card based systems involve three parties: the buyer (or customer), the seller (or merchant), and the acquirer gateway (the intermediary between the payment model and the card issuer). In 1KP, only the acquirer holds a public key pair. Buyers and sellers only need copies of the acquirer’s public key, which requires minimal use of a public key infrastructure (PKI) to provide public key certificates for the acquirers. In 2KP, both the acquirer and the seller maintain public key pairs and public key certificates, while in 3KP all three parties hold public key pairs and public key certificates, requiring a full public key infrastructure. The purpose for the various designs was to allow a gradual deployment as the public key infrastructure grew. All versions of iKP can be implemented in either hardware or software. It is also important to note that the goal of iKP is only to enable payments, therefore the protocols are not concerned with any aspect of the order process[2,3]. Secrecy and encryption of the order information is assumed to be provided by other existing methods, such as SSL. Overall, iKP provides a very strong and secure starting point for providing standards for electronic payment systems, as well as providing flexibility to adapt to specific needs in a variety of systems.
2. iKP History.
iKP was developed in 1995 at IBM Research Labs with the initial goal of becoming an open industry standard. Although many other payment protocols were introduced around the same time as iKP, they were merely theoretical designs while iKP consisted of a fully operational prototype. This prototype was known as ZiP for the Zurich iKP Prototype. Interpay Nederland still uses ZiP in their I-Pay system which supports 80 online merchants and 17,000 card holders[2].
iKP was designed to be simple and modular, as well as to allow for a gradual deployment. iKP concentrates only on the core payment functionality and leaves all other functionality, such as ordering and shipping, to be added on top of iKP. Other payments models incorporate more functionality into the actual payment protocols, providing less modularity. Currently the main approaches for secure credit card payments over the Internet are SET (Secure Electronic Transactions) and encryption using SSL (Secure Socket Layer). SET is very similar to iKP, but more complex. SET supports all options available with modern credit card operation, which makes it more difficult to analyze and deploy. However, an understanding of iKP will provide a basic understanding of SET. SSL uses public key cryptography, like iKP and SET, but only the servers maintain public key certificates while the buyers remain anonymous. This does not provide the level of payment security that iKP and SET provide: the merchant does not gain any security as the use of SSL is transparent to the acquirer so no messages are signed; credit card numbers and other information are not hidden from the merchant; the public key infrastructure does not guarantee that a buyer can verify a merchant; and other mechanisms are needed to transmit other payment information[2]. iKP and SET provide a complete solution to all of the shortcomings of SSL. However a limitation of iKP is that it cannot necessarily be applied to payment models that differ greatly from the bank card model.
3. The iKP Payment Model.
The iKP protocols are based on the existing credit card payment system. The payment system involves three parties: the Buyer, the Seller, and the Acquirer gateway. The Acquirer is simply a front-end to the current unchanged infrastructure for credit card clearing and authorization. It is assumed that credit cards are issued to buyers from banks, called issuers. Each bank has a Bank Identification Number (BIN) which is part of the credit card numbers. It is also assumed that each Buyer receives a credit card from an issuer and also maintains a PIN (Personal Identification Number) and that the Buyer is using a computer to utilize the payment protocol. The computer used must be trustworthy. A vulnerability is that the computer could contain viruses or Trojan horses that could compromise the PIN or secret key. A totally secure payment device can be devised by attaching a smartcard reader with its own display and keyboard to the computer. This is known as an electronic wallet. 1KP and 2KP can be used with any device, but 3KP requires a secure device, such as an electronic wallet, to store the Buyer’s secret key and certificate. It is assumed that the Seller signs up with a payment system provider and a bank, called the Acquirer, to accept the transactions. Therefore the Seller also requires a secure device for storage of the secret key and to execute the payment method[2,3].
Several assumptions are made in iKP regarding what information the parties hold in advance concerning public keys and encryption. All iKP protocols make use of public key cryptography so the assumption is made that Certificate Authorities (CA) exist to authenticate the public keys. Each Acquirer has a secret key (SKA) for signing and decryption. The Acquirer’s public key (PKA) is used for signature verification and encryption. It is further assumed that each Seller holds PKA and its corresponding CA certificate. Acquirers will receive the Buyer’s credit card number and PIN and are assumed to keep these values confidential.
Three different types of threats are considered in iKP. An Eavesdropper listens to messages and tries to learn the credit card number, PINs, etc. An Active Attacker attempts to change what the system does by introducing false messages. An Insider is a legitimate party or someone who learned a party’s secrets and uses the information obtained in a malicious way (such as attempting to receive payment without authorization). The decentralization of the Internet enables adversaries to create fictitious electronic stores in an attempt to learn credit card numbers. For this reason,it is extremely important that a Buyer’s information travel from the Buyer to the Acquirer without revealing the information to the Seller. Keys must also be protected with an extremely high level of security, although iKP does not prescribe any method for this.
4. Security Requirements of iKP.
There are several mandatory security requirements for each party in the payment model in order for the protocol to work successfully. The design of iKP also allows for optional features and security requirements to be added.
The issuer and the Acquirer utilize the existing, assumed secure, infrastructure, and retain mutual trust, therefore their security requirements are combined. The first security requirement, A1, is proof of transaction authorization by the Buyer. This means that the Acquirer must have unforgeable proof that the credit card owner has authorized the payment and the proof must not be subject to replay attacks. The proof should certify the amount, currency, merchandise description, seller identification, and delivery address and not allow a dishonest seller to create an unauthorized debit. A weak proof, (a), simply authenticates a Buyer to the Acquirer, while an undeniable proof, (b), would provide full non-repudiation. Requirement A2 is proof of transaction authorization by the Seller, meaning that the Acquirer must have unforgeable proof that the seller requested the payment be made to him.
There are also two security requirements for the Seller. S1 is proof of transaction authorization by the Acquirer. The Seller must have unforgeable proof that the Acquirer has authorized the payment. The Seller must certify and authenticate the Acquirer and certify the authorization information, including the amount, currency, time and date, and transaction identification. Again, a weak proof, (a), would provide authentication of the Acquirer to the Seller, while an undeniable proof, (b), would also provide non-repudiation. Security requirement S2 is proof of transaction authorization by the buyer. The seller may need unforgeable proof that the Buyer has authenticated the transaction even before the Seller receives the authorization from the Acquirer. Once again, a weak proof, (a), or an undeniable proof, (b), can be used.
The Buyer has four main security requirements, as well as two optional requirements. Security requirement B1 is the impossibility of an unauthorized payment. Obviously, without the Buyer’s credit card number, PIN, and secret key in 3KP, it should be impossible to charge the Buyer’s account. Legitimate information must not be able to be replayed to create a spurious transaction. The PIN cannot be sent in the clear or be subject to guessing attacks. In the case of B1, impossibility means that it is completely impossible for unauthorized payments to be made (as long as the Buyer is honest and his secret key has not been compromised). Disputability means that the Buyer is able to prove that a payment was unauthorized, even if the Acquirer’s secret key has been compromised. Note that these requirements are generally met when requirements A1.a and A1.b are met. Requirement B2 is proof of the transaction authorization by the Acquirer. Although not absolutely necessary, the Buyer may want proof that the Acquirer actually authorized the transaction. Once again there is weak proof, (a), and undeniable proof, (b), which provides full non-repudiation. B3 is certification and authentication of the Seller. The Buyer must have proof that the Seller is accredited at a known Acquirer. Receipt from the Seller is the final necessary requirement, B4. This means that the Buyer may need proof that the correct Seller has received payment and will deliver the merchandise. If the Seller refuses to send this ‘receipt’ after receiving authorization from the Acquirer, the Buyer can use his next statement of account as the receipt[2,3].
The optional requirements for the Buyer are, B5, privacy and, B6, Anonymity[2]. The Buyer may want the order and payment information kept private. The Buyer may also want to remain anonymous from eavesdroppers, the Seller, or even the payment system provider. iKP is not concerned with anonymity and has no mechanism for providing anonymity from the payment system provider. However, the exposure of the Buyer’s identity to the Seller and outsiders is minimized by iKP.
5. The iKP Protocols.
Certain initial information is assumed to be known by each party. For example, the Buyer has the public key of the certificate authority (PKCA), the Seller has the certificate of the Acquirer (CERTA), and the Acquirer has his own certificate (CERTA) and the corresponding secret key (SKA). Other information may be known depending on the value of i. It is assumed that the Buyer and the Seller have already agreed on the price of the items to be bought, so DESC and AUTHPRICE are also part of the initial information of the Buyer and Seller. The basic iKP protocol will consist of five flows: the Buyer starts the process with the Initiate flow, the Seller then responds with an Invoice, the Buyer commences the Payment flow used by the Seller to transmit an authorization request to the Acquirer (Auth-Request flow), the Acquirer then uses the financial network to authorize the transaction, and provides the Auth-Response flow back to the Seller, and, in the final flow, the seller sends a confirmation flow (Confirm) back to the Buyer.
1KP: In 1KP, public key encryption is used by all parties, but only the Acquirer must possess and distribute a certificate, CERTA. All Buyers and Sellers must have an authentic copy of the certification authority’s public key, PKCA. The Buyer, B, has a credit card number, an expiration date, and possibly a PIN number. The Seller, S, must know CERTA and be able to forward it to B. Note that iKP does not describe the transportation method for the certificates. Generally the assumption is made that the certificates are piggybacked onto the iKP messages. The authorization of the transaction uses the tamper resistant technology of the existing authorization infrastructure to process and verify B’s information. In 1KP, encryption takes place only one time: when B sends the account data. Decryption of the information is only done by the Acquirer, A. Signatures are only used by A and verified by both B and S.
The Initiate flow begins with the Buyer creating an Identification number (IDB) using a hash of a randomly generated number (RB) and the Buyer’s Account Number (BAN). Thus IDB = HASH(RB , BAN). The Buyer will also generate another random number (SALTB) to use for salting the hash of the merchandise description (DESC).
The Invoice stage begins when the Seller receives the Initiate information. The Seller extracts SALTB and IDB from the Initiate flow, generates a nonce (NONCES) and sets the DATE timestamp. The NONCES and DATE are used by A to uniquely identify the transaction, NONCES dispels any ambiguity of transactions with the same DATE. The transaction identifier (TIDS) is then set, the hash of (SALTB , DESC) is computed, and the hash of COMMON is computed. COMMON is a composite field consisting of AUTHPRICE, IDS, TIDS, DATE, NONCES, IDB, and HASH (SALTB , DESC). Note that since the already salted hash of (SALTB , DESC) is included in COMMON, it doesn’t need to be salted[2,3]. CLEAR, which consists of IDS, TIDS, DATE, NONCES, and HASH(COMMON), is then transmitted to B as the Invoice. CERTA can be sent with this message or sent to B later.