The Netscape Electronic Payment System Taher Elgamal Netscape Communications Corporation ========== Agenda o Objectives and Philosophy o Description o Security o Efficiency o Flexibility ========== Philosophy o Use standard formats and messaging whenever possible - X.509 certificate format(s) - PKCS content format - ASN.1 message wrappers - Standard algorithms for cryptographic operations o Open system o Incremental migration from the current systems, keeping the authorization and clearing operations separate o Can use customer certificates but does not require them ========== Objectives o Design Objectives - Allow for credit, debit cards and other accounts as well as Micro Payments - Support (but do not require) user certificates, as well as PINs for verifying the user's identity - Allow for different authorization rules by the issuing banks - Allow for staged adoption by financial institutions - Allow for immediate and delayed delivery of goods - Allow merchants to maintain the same acquiring bank relationships they have today - Reduce the exposure of confidential information including credit card numbers in the clear - Allow for full auditability of transactions - Strong encryption for international use ========== Description ------------ ------------ | | | | | Customer | | Merchant | | | | | ------------ ------------ /\ /\ || || || || \/ \/ ------------------------------------------------------ /\ || || \/ _______ ----------- / \ | | | Banks |<=====>| Payment | \_______/ | Gateway | | | ----------- ========== Payment Protocol Description Customer <-- SSL --> Merchant <-- SSL --> Payment Gateway Order, ESlip --------------> ESlip, H(Order) ---------------> Authorize through bank network Auth Response <--------------- Receipt <-------------- The Basic Authorization Mechanism ========== Payment Protocol Description Customer <-- SSL --> Merchant <-- SSL --> Payment Gateway Clearing Req. ----------------> Clearing Response <===EMAIL <----------------- Signed Receipt <-------------- Confirmation ---------------> The Basic Clearing Mechanism ========== Payment Protocol Description Customer <-- SSL --> Merchant <-- SSL --> Payment Gateway Order Inquiry --------------> Order Status <-------------- Asynchronous Operations at any stage ========== Detailed Message Formats o Date and time attached to all messages for all nodes to check, but also a transaction ID us used to prevent replays o Optional acknowledge messages to verify receipt of each message o Required data by the customer prior to starting the payment protocol: - Public key and certificate of the acquirer (gateway), Unique transaction ID number (TID), Merchant ID (MID), Total amount including tax and shipping charges o The Purchase-Order Message - Items, total amount, shipping address o The ESLIP Message - PKGateway{K},K{account number, PIN, total amount, billing address, transaction ID, Merchant ID} ========== Detailed Message Formats o Auth-Request Message - ESLIP, Hash(Purchase-Order), MID, TID o Auth-Response Message - Response-Code, Auth-Code, MID, TID o Receipt Messages - ESLIP, Hash(Purchase-Order), Auth-Code signed by the merchant, with an optional confirmation signed by the customer, MID, TID o Clearing Messages - Similar to Auth messages, however, cannot be replayed because the issuing bank will refuse to do multiple clearing on the same Auth ========== Detailed Message Formats o Each message is composed of its parts using ASN.1 format -- allows for optional parts easily o A PKCS wrapping is used for all messages -- can easily attach signatures to any message, can also apply encryption easily o Separate ESLIP encryption allows for better export algorithms ========== Security o Connection Security: Using SSL between the customer and the Merchant and between the Merchant and the Payment Gateway o Credit card security: Using the Gateway's public key to encrypt the Slip o Hashing the order at the Merchant prevents man-in-the-middle attacks o An Order number (unique transaction ID) prevents replay attacks at the Merchant o All other replay attacks are prevented by SSL o The Credit card number is not seen by the Merchants -- only the banks o The Order is not seen by the banks -- only the payment information ========== Security o ESlip = (Account Number, expiration date, total amount, billing address, unique order number), all encrypted to the payment gateway as a digital envelope o Any message can be signed by the originator if needed, the PKCS message format allows for automatic retrieval and verification of the data o The "Order Inquiry" message can be sent at any time with the appropriate response status from the Merchant, for example, not authorized yet, authorized but waiting for shipment, and so on. The content of the message is SSL protected o Receipts are sent to the customer using secure email, or an email notification if the customer's browser does not support secure email. The customer can then retrieve the receipts ========== Efficiency o SSL for establishing session and connection security - Master key for several sessions generated using public keys - Sessions keys generated using MD5 - Avoids using digital signatures as authenticators when not needed as a long term signature o The payment protocol focuses on payments and uses features in SSL o Uses signatures and public key operations only when needed or required by the policy ========== Flexibility o Does not require certificates for customers, however, requires certificates for merchants and payment gateways o Can be applied to many payment models o Produces receipts and other confirmation information that are cryptographically secure o Can use digital signatures o Customer can inquire about order status at any time o Can be used for immediate delivery, delayed delivery, goods returns and so on o Different message groups are done separately - Authorization - Clearing - Settlement and batch processing ========== Flexibility o Separate authorization and clearing as well as combined authorization and clearing are supported o PINs, address verification fields are supported o Can interface to multiple acquiring banks o Supports many "rule" sets o Produces receipts and records for integration into customer financial records ========== Other Features o Support for recurring payments such as subscriptions, without customer intervention o Support for partial shipments o Support for multiple acquires for authorization and clearing o Capability of hiding the identity of the Acquirer from the customer o Support for longer signature keys (vs. key exchange keys) o Support for customer certificates that are issued by financial institutions -- but does not require the customer certificate -- may depend on some policies of the issuing banks