Set Cardholder Wallet - Doch Project Documentation

S E T C A R D H O L D E R W A L L E T
W I T H
J A V A C A R D S U P P O R T

(design decisions and underlying working assumptions)

Secure Electronic Transaction (SET) protocol [1] secures card transactions on the Internet. In order to attract customers it has to be easy to use. However, the usability and ergonomics were not taken into account by many Cardholder's products based on SET. This results in low acceptance of the SET protocol. The customer does not like to:

ask for CD's or download the software
install Wallet
experience problem during the installation
retrieve the SET Certificate with the password problem
understand what has been accomplished

To reduce these drawbacks we propose NEW SET Wallet architecture:

The SET Wallet should be made up of two separate Java programs. The first program, the SET Network Part, is implemented as signed Java Applet. This Applet is downloaded over the Network every time the cardholder decide to pay for the goods. After the downloading is accomplished the Java Run Time checks the Applet signature. Since the applet will access the cardholder Chip Card this step is mandatory. The second program is a cardlet located onto the Cardholrder's Java Card. The card contains the sensible carholder data. These data are the Primary Account Number, Card Secret, Cardholder Private Key, and the Public Key of the Payment Gateway if the cardholder participate on the local credit plane. The other function of the card is to generate the data structures which are required to construct the payment message in a secure manner. This structures are, here and after in terms of ASN.1, PIData and hash from it, PIDualSignedTBS and DES encryption from it, application of the cardholder signature key, OAEP on PANData and than it encryption with payment gateway public key.
SET functions are shared between these two Java applications. The Java Card contains primary account numbers (PANs) and minimal SET functionality to prevent the disclosure of the Cardholder's sensible data. The Network Part contains the functions required to construct the SET messages from the components provided by the card and to exchange the messages with merchant Point of Sale (POS).

The sharing of SET functions is created by a partition of the protocol specification (for further references see doc/Doch.ppt), which is different from other solutions called to solve the SET deployment problem. (E-COMM, CSET, ServerWallet, Server-Stored Wallet.)

The Java Card contains (approximate calculation):

	PIHead (payment instruction data) PANData (primary account data structure) cardSecret (Cardholder's part of shared secret value) ipad buffer (needed to generate transaction stain) opad buffer (needed to generate transaction stain) PIDualSignedTBE (DES encrypted part of envelope) the link to cardholder certificate (URL) cardholder modulus cardholder private exponent cardholder signature encryption block payment gateway modulus payment gateway public exponent OAEP block intermediate OAEP result - SUB_H1 (need to compute H1) intermediate OAEP result - H1 intermediate OAEP result - H2 certificate buffer (not used in this implementation) hash of the root certificate cardholder name brandname	902 bytes 75 bytes - 84 bytes 84 bytes 1010 bytes 200 bytes 128 bytes 128 bytes 128 bytes 128 bytes 3 bytes 128 bytes 17 bytes 120 bytes 20 bytes 1500 bytes 20 bytes 30 bytes 64 bytes		[1, page 273] [1, page 283] [1,p.56] [1, page 96] [1, page 96] [2, page 193] [1, page 100] [1,p.103] [1, page 103] [1, page 103]
	TOTAL MEMORY the actual size of program cap file	3784 bytes 9369 bytes

cardSecret is XORed with ipad and opad buffer at the time of the personalization

The card contains the Cardholder's private key and the URL to the certificate instead of the certificate itself. Therefore, significant memory saving is achieved. SET Cardlet implements follow functions:

the construction of PIData and its hashing. Actually, the PIData is never constructed as a byte array, but hashing is applied to its components which in their case are the subpart of other data.
the last stage of the construction of PISignature [1, page 52]. this means that we
1. construct the Authenticated Attributes with the hashed PITBS outside of the card.
2. put to the card the hash of step 1.
3. get from the card the signed hash of step 2. with 1024 Bit RSA encryption
  of PISignature with cardholder private key.
up to 1010 bytes of the DES encryption of PIDualSignedTBE.
construction of the OAEP block.
1024 Bit RSA encryption of the OAEP block with the payment gateway public key.
generation of transaction stain.

To keep the size of the cardlet as small as possible, the structures PIData, opad, ipad, PIDualSignedTBE and cardholder signature encryption block contains the maximum of data that were calculated at the time of the personalization. There are following data, which are known at that time:

PAN - primary account number [1, pages 33,213], [2, page 20].
CardExpiry - account expiration date [1, page 213], [2, page 20].
panSecret - shared secret value [1, page 273], [2, page 20].
BIN - Cardholder's bank ID [1, page 136], [2, page 72].

The SET Network Part communicates with the SET Cardlet by Open Card Framework (OCF, http://www.opencard.org). OCF is a standardized application platform written in Java and provides the programmer with a card and a card terminal access API. The access to the resources on the local host is managed by Java 2 Policy File.

The Wallet can communicates with any conventional SET merchant software. We have test it with GlobeSET POS 1.2 and SETREF implementation. In our demonstration, the program exchanges PInitReq/PIniRes, PReq/PRes with SET reference implementation (SETREF) and passes all tests .

The program supports the following operations. The customer downloads SET Cardlet to its Java Card while visiting the issuer service point. In some cases the issuer will send the Java Card and preloaded SET Cardlet to the customer per mail. This will depend on the issuer business policies. After accomplishing this step the Cardholder is ready to carry out SET transactions. There is also possibility to download the cardlet onto the card online and then remove it from the card after the payment is accomplished. We currently work out this possibility.

Upon completing the shopping experience, the Cardholder presses the button "Load Wallet" on the merchant web site. The SET Network Part (Wallet) implemented as Signed Java Applet and maintained on the Wallet Software Provider Web Site should be loaded on the Cardholder's machine. Upon verifying the Software Provider signature, the Browser passes the execution to the SET Network Part. The SET Network Part seeks for a terminal device.

Upon establishing the connection to the card reader, the applet requests the cardholder to insert the Java Card and type in the PIN. The SET Cardlet verifies the PIN on the Java Card and than signals the SET Network Part to be ready for further computations. The SET Network Part downloads and parses the Wake Up Message from the merchant POS. Typically, this message contains order information and supported brands. The SET Network Part requests the available brands from the card and than provides the order information and the brands suitable for current payment to the Cardholder. The Cardholder selects one of them and presses the "Pay" button.

The SET Network Part exchanges the PInitRes and PInitReq messages with merchant's POS and than processes the PInitRes message according to SET Specification [1, page 307]. The use of Java Card extends this specification with several new features. The Payment Gateway certificate chain extracted from the PInitRes is provided for verification of trust hierarchy to the SET Cardlet.

The first certificate in the chain is the root certificate and should be sent to the card first. Its verification requires generation of message digest and comparison of this digest with the value stored on the card at the time of the personalization. Upon completing the verification of the root certificate, the SET Cardlet saves the root public key on the card and is ready to process the next certificate from the certificate chain. The next received certificate overwrites the previous one. This is done due to the memory limitation. The SET Cardlet verifies the signature of this certificate whether it was signed with the root public key. In that case the SET Cardlet accepts this new certificate and overwrites the previous stored public key (in this case root) with the new one. This operation repeats 5 times. The fourth certificate received will be accepted as payment gateway certificate and its public key as the payment gateway public key.

There is another solution to provide the Payment Gateway Public Key to the SET Cardlet. The key could be stored on the card at the time of personalization. This less flexible solution limits the number of merchants that are available to the cardholder, but has memory and security advantages. This model suitable for small card plans and is currently used in our implementation.

In the next step, the SET Network Part follows the SET specification [1, page 318] and generates PReq -- the most important payment message. To construct this message the SET Network Part sends PIHead, XID, and hashed OIData to the SET Cardlet. As a result the applet gets TransStain, DES encryption of PIDualSignedTBE, RSA encryption of OAEP with payment gateway public key and RSA encryption of hashed authenticatedAttributes with Cardholder's private key (Cardholder's signature) from the cardlet. Upon receiving these data, the SET Network Part constructs the PReq message and sends it to the merchant POS.

Finally, the SET Network part receives PRes -- the response message -- and processes it according to the specification [1, page 336].

PUT BRANDID Command : 84 DA 01 02 Input Data : <nn bytes with BrandID> Status : 90 00 Summary: This is a personalization command. PUT PAN Command : 84 DA 01 04 nn Input Data : <up to 19 bytes with cardholder primary account number> Status : 90 00 Summary: This is a personalization command. PUT CARDEXPIRY Command : 84 DA 01 0A 06 Input Data : <6 bytes with card expiry> Status : 90 00 Summary: This is a personalization command. PUT HASH ROOT Command : 84 DA 01 08 14 Input Data : <20 bytes of hash of the root certificate> Output Data : none Summary: This is a personalization command. PUT PANSECRET Command : 84 DA 01 0C 14 Input Data : <20 bytes of pan secret> Status : 90 00 Summary: This is a personalization command. PUT CARDSECRET Command : 84 DA 01 0E 14 Input Data : <20 bytes of card secret> Status : 90 00 Summary: This is a personalization command. PUT URL Command : 84 DA 01 14 nn Input Data : <the URL to the cardholder certificate> Status : 90 00 Summary: This is a personalization command. PUT USER PRIV EXP Command : 84 DA 01 10 80 Input Data : <the 128 bytes with cardholder private exponent> Status : 90 00 Summary: This is a personalization command. PUT USER MOD Command : 84 DA 01 12 80 Input Data : <128 bytes with cardholder rsa modulo> Status : 90 00 Summary: This is a personalization command. PUT PGW PUB EXP Command : 84 DA 01 2C 03 Input Data : <up to 5 bytes of payment gateway public key exponent> Status : 90 00 Summary: This is a personalization command. PUT PGW MOD Command : 84 DA 01 2A 80 Input Data : <128 bytes of payment gateway rsa key modulus> Status : 90 00 Summary: This is a personalization command. PUT USERNAME Command : 84 DA 01 2E nn Input Data : <the user name> Status : 90 00 Summary: This is a personalization command. There are the following APDU used for communication with the card: GET BRANDID Command : 80 CA 01 02 nn Output Data : <the brand ID> Status : 90 00 Summary: This is a production command. The command with 0x00 expected length should be issued before. GET BIN (bank identifier) Command : 80 CA 01 06 06 Output Data : <get the bank ID> Status : 90 00 Summary: This is a production command. GET HASH ROOT Command : 80 CA 01 08 14 Output Data : <return 20 bytes of root certificate hash> Status : 90 00 Summary: This is a production command. PUT PIHEAD Command : 80 DA 01 16 nn Input Data : <The PIHead data structure, der encoded> Status : 90 00 Summary: the PIHead data structure is placed inside the card. Several subsequent command could applied. The cardlet analyze the header of the message and then receive no more byte than was specified in der encoding of PIHead. Cardlet Performs ASN.1 processing of this structure and finds there the XID and the empty slot for transaction stain. This is a production command. GET URL Command : 80 CA 01 14 21 Output Data : <the URL to the certificate> Status : 90 00 Summary: The command with 0x00 expected length should be send first. This is a production command. GET USERNAME Command : 80 CA 01 2E nn Output Data : <the user name> Status : 90 00 Summary: The command with 0x00 expected length should be send first. This is a production command. PUT HASH OI (Put hash of OIData) Command : 80 DA 01 18 14 Input Data : <20 bytes hash> Status : 90 00 Summary: the data is placed into the DetachedDigest structure (dd_oid) This is a production command. GET DES IV (Initialization Vector) Command : 80 CA 01 28 08 Output Data : <8 bytes with initialization vector> Status : 90 00 Summary: The DES used for encryption of PIDualSignedTBE data. The DES key is placed in OEAP slot. After receiving this data, the card constructs and encrypts PIDualSignedTBE data. This is a production command. GET DES ENCRYPTED PIDualSignedTBE Command : 80 DA 01 1C 80 Output Data : <a number of bytes from 1 - 251> Status : 90 00 or 61 nn Summary: The command gets the PIDualSignedTBE data. If more data remains inside the card, the one ore more subsequent GET RESPONSE command with APPLICAtION CLASS [0x80] should be used (ISO7816). This is a production command. PUT HASH FOR PI SIGNATURE Command : 80 CA 01 24 14 Input Data : < 20 bytes of hash value> Status : 90 00 This is a production command. GET SIGNED HASH of Authenticated Attributes with PI-TBS digest. Command : 80 DA 01 26 80 Output Data : < 128 bytes of encryption of PKCS-1 padded HASH Status : 90 00 Summary: The signature block is signed with cardholder private key and returned from the card. This is a production command. GET ENCRYPTED OAEP BLOCK. Command : 80 DA 01 22 80 Output Data : < 128 bytes of OAEP encrypted block> Status : 90 00 Summary: The OAEP Block is encrypted with PGW public key and returned from the card. This is a production command.

REFERENCES

[1]	Visa, MasterCard, SET Secure Electronic Transaction Specification, Book 2: Programmer's Guide, Version 1.0 http://www.setco.org/download/set_bk2.pdf
[2]	Visa, MasterCard, SET Secure Electronic Transaction Specification, Book 3: Formal Protocol Definition, Version 1.0 http://www.setco.org/download/set_bk2.pdf