Digital certificates and payment systems

Information Security Technical Report, Vol. 2, No. 4 (1998) 23-31

Digital Certificates and Payment Systems Michael Ward, Standards and Security Unit Association for Payment Clearing Services

This article provides a brief overview of the kinds of digital certificates that are used in some electronic payment systems; namely S. W.I.F.T., CHAPS, EMV and SET. These electronic payment systems use public key certificates to protect the integrity and confidentiality of payment and key management messages. The information held in certificates varies by application: S. W.I.F.T. and CHAPS operate over private networks, have a limited membership and can use simple certificates; EMV also uses short certificates - but it has to because of the scarcity of ICC memory; SET on the other hand does not sufer this cons train t and can use relatively long certijca tes that support a wide variety of participan ts.

This article gives a brief introduction to each payment system and for each describes the type of information contained in a certificate; it does not go into the detailed operations of the actual payment system. We begin by reviewing why certificates are needed, what they are, and how they are used and managed. We assume the reader has a basic understanding of public key cryptography.

1. A Brief Introduction to the use of certificates

Public key cryptography enables the creation of digital signatures and half solves the problem of efficiently distributing secret symmetric keys. However, there still remains the problem of how to securely distribute and manage the public keys, albeit in an authenticated rather than a confidential manner. It is for this purpose that public key certificates are used.

A (public key) digital certificate is a digitally signed data record (not a sealed scroll as illustrated in Figure I!) that contains, at a minimum, a public key and the name of the owner of the public key. It is created by a

certifier or Certification Authority (CA). The CA digitally signs the data record and thereby attests to the ownership of the public key therein.

Certification Architectures

In order for Alice, in Figure 1, to authenticate Bob’s public key certificate she needs an authentic copy of the CA’s public key. This can be done using a certificate of the CA’s public key created by another CA. Such an approach can be extended to a chain of CAs, each CA certifying the public key of the next in the chain, however ultimately Alice will need a ‘trusted’ public key whose authenticity does not depend on the digital signature of another CA. A trusted public key could be obtained by a variety of methods e.g. on a diskette from a trusted person or organization. Alternatively one might obtain a public key (initially untrusted) and subsequently corroborate its authenticity by comparing its digest with trusted digests appearing in standard publications.

All sorts of certification architectures are possible, ranging from strict hierarchies through to free-form networks, and whilst in theory there is no limit to the number of certificates in a certificate chain, in practise the effort needed to traverse back through the chain to the trusted public key can be a significant limitation. Rather than avoid long certificate chains, an end user may choose to delegate all or some of the time consuming certificate verifications to a trusted third party. Application requirements and constraints will dictate which approach is best.

Certificate Life-Cycle

After a subscriber’s public key pair has been generated they can submit the public part of it (and other necessary information) to a

0167-4048/98/$19.00 0 1998, Elsevier Science Ltd. 23

Digital Certificates and Payment Systems

“Bob” P Figure 1.

Registration Authority. The Registration Authority then submits the subscriber’s public key (and other necessary information) to a CA. The CA then creates the signature on the certificate, and the certificate is then distributed as required.

The Registration Authority must ensure that the entity identified in the certificate (as being the owner of the certificate) is indeed the subscriber. They may additionally need to check that the subscriber possesses the private key corresponding to the public key. It is possible for a CA to perform the duties of a Registration Authority.

Certificates should contain a ‘validity period’ which at a minimum defines when the certificate expires. It may be necessary to revoke a certificate prior to its expiry date - for instance its owner may suspect that their

private key has been compromised. Certificate Revocation Lists (CRLs) are lists of certificates that have been revoked and these are typically maintained by a CA. CRLs should be consulted as part of the certificate verification process. A certificate might also appear in a CRL as being ‘suspended’ rather than ‘revoked’. This is a temporary revocation implying that the certificate might become valid again prior to its expiry date.

We now proceed to an overview of the certificates used in CHARS and S.W.I.F.T..

2. Wholesale Payments - CHAPS and S.W.I.F.T.

Clearing House Automated Payment System (CHAPS) is the UK payments system for handling high value payments (average value in 1996 of E2.5 million). It operates a CA that

24 Information Security Technical Report, Vol. 2, No. 4


issues public key certificates to each of its 16 Society for Worldwide Interbank Financial member banks. These certificates (and their Telecommunication (S.W.I.F.T.) operates an associated public key pairs) are used for international network for transferring securing the bilateral distribution of payment messages between its thousands of symmetric keys between the banks. The banks worldwide members. It operates a two-tier then use the symmetric keys for CA system (in much the same way as CHAPS) authenticating payment messages sent for enabling its members to establish between each other. authentication keys between one another.

I Bank I

CHAP!3 has recently been upgraded to allow Real-Time Gross Settlement (RTGS). This improved system allows payments to be settled in real-time rather than at the end of each day (i.e. a CHAPS payment between two banks causes an immediate change to their accounts at the Bank of England). An upshot of RTGS is that Members must continually monitor the state of their account at the Bank of England in order to ensure that they have sufficient (and yet not too many) funds in their account. The Bank of England operates a separate CA that provides public key certificates to the treasury departments of CHAPS Members so that they can securely enquire upon the status of their accounts.

Both CHAPS and S.W.I.F.T. operate over private networks and use certificates based upon IS0 11166l. In accordance with IS0 11166, each member generates a private key pair and then obtains a public key certificate from the CA. A symmetric authentication key can now be sent securely from one member to another: the sender first verifies the authenticity of the recipient’s public key (using its associated certificate and trusted CA public key), they then encrypt a symmetric key under the recipient’s public key and sign the result using their own private key. In a similar way, the recipient first authenticates the sender’s public key, they then use the sender’s public key to authenticate the received symmetric key and their own private key to decrypt it.

IS0 11166 certificates come in essentially three sizes: short, medium and long (although all are relatively short compared with other certificates discussed in this article). They contain the following information (see Table 2).

‘Format and Function code’ is a single byte

Table 2. ’ IS0 11166 Banking - Key management by means of asymmktric algorithms

Information Security Technical Report, Vol. 2, No. 4 25


that indicates the certificate content (e.g. ‘long certificate’), the data representation/format and the function of the public key (signature, encryption or both). The algorithm used to sign the certificate is RSA in either a ‘message recovery mode’ or ‘message hash mode’.

Long certificates specify dates and time as YYMMDDHHMMSS, whereas short and medium certificates only have YYMM.

With long certificates the certificate owner is identified by 16 alphanumeric characters, whereas short certificates use four decimal digits and medium certificates use an eight character Bank Identifier Code.

payments specification defined by Europay Mastercard Visa (EMV). EMV defines a CA architecture with an additional layer.

3. Card Payments and IC cards

EMV is a specification developed by Europay, Mastercard and Visa for making credit and debit card payments using an IC chip embedded on the card. These chips can store digital certificates and symmetric keys for MACing and encryption, and the most powerful can digitally sign and verify messages.

Credit and debit card payments involve essentially five types of participant:

‘Public Key info’ contains the RSA modulus of the key-pair being certified (the public exponent is assumed to be an application- wide constant).

.

. The next section describes a chip card

Cardholders, people that possess a credit card or debit card.

Issuers, banks that issue cards to cardholders and with whom the

Issuing Bank Acquiring Bank

Transaction details on statement

Cardholder Retailer

Figure 2: Curd Payments model.

26 information Security Technical Report, Vol. 2, No. 4


cardholder has an account.

?? Retailers, merchants that sell goods and services to cardholders.

those of CHAP!5 and S.W.I.F.T., their content is necessarily restricted by the physical

I

?? Acquirers, banks that will accept card transactions from retailers and with whom the retailer has a contractual relationship.

?? Schemes, card associations such as Visa, Mastercard and Europay that oversee the payment system and who proyide the network that links Issuers to Acquirers.

With this set-up cardholders and retailers do not need an LJ priori relationship because a trading relationship is established via the Issuer, Scheme and Acquirer (see Figure 2).

I I

I t

I b

Cardholder I I

I 4

The purpose of EMV certificates is to enable a retailer’s electronic Point-of-Sale (POS) terminal to authenticate information held on the card (and signed by the Issuer) and verify digital signatures generated by the card (if the card is capable of generating them). Note that EMV additionally defines a symmetric key authentication protocol between the card and issuer.

constraints and computational power of the chip cards and the POS terminals.

EMV certificates contain the following information (see Table 2).

. Note 1: For a cardholder this is the Primary Account Number (PAN), for a card issuer it is the leftmost 3-8 digits of the PAN.

. Whilst EMV certificates are more generic than

Note 2: EMV was designed with a specific signing technique in mind, namely SHA-1



Table 3.

In

x509 version {e.g. v3) issuedbythesameG4

to create the Certificate

and associated &&&thm object identifier

WTKMAL CPMONAL

. .

with RSA giving partial message Govery (as per IS0 9796-2). With this technique some of the signed information can be recovered from the signature (the first nine fields) whilst the remainirig information must be sent ‘in clear’ along with the signature (the final three fields).

order to verify an EMV certificate, the

verifier must also know the CA public key and signing algorithm - this information is not included in the EMV certificate. Scheme public keys are stored securely in the retailer’s POS terminal(s).

4. Generic certificates

EMV certificates are fairly short because of the

Table 4.

signature on a certificate. It enables distinct keys

enables distinct keys used by the same subject to be

blic key is used: pherment, keyAgreement,

a the certified pub&~ key. A is appIicabIe avauability of a tr&ed time stamp

is expressly rem@& as supporting. The 2zri&r w&c& the cert#icate was emate&

taneormore issuer’s cex%ificate policies is ~U~~~ A’s domain. Thisextension

z&E? %Bmvever$ &is In only be practiizaI in limited I ts are very simple.

ct.

the subject of the tzerscatt?. public key to sign certificates.

icy identification or inhibit

icate user should refer to



physical constraints of the chips used, and 11166 certificates are able to be very simple because the application context defines much of the information (e.g. algorithm). If the context in which a certificate is to be used is not so pre-determined then more generalized certificates are needed. To this end the ITU and ISO/IEC have jointly defined the basic information (and its format) that should be contained in a general certificate. The minimum information as defined by the equivalent standards X.509 (ITU) and 9594-8 (ISO/IEC) is seen in Table 3.

Version 3 of X.509 defines additional information that might be contained in a certificate. These are known as ‘extensions’ and are seen in Table 4.

The next Section describes a payment system whose certificates are based on X.509.

5. Payments Over the Internet

Secure Electronic Transaction (SET) is a protocol specification for securing credit and debit card transactions over the Internet. SET uses certificates based on X.509. It was developed by a consortium including Visa and Mastercard. Unlike EMV where the end user’s computing resource is essentially an IC, SET is designed for cardholders with the computing resource of a home or office computer.

Messages for making payments and ordering goods are communicated between the cardholder’s computer, the merchant’s computer and the Acquirer Payment Gateway (APG). The APG is a computer operated by the Acquirer that provides a gateway into the Scheme network. Cardholder, merchant and APG are typically assumed to communicate over an open network such as the Internet.

Root CA Signature

$ Brand CA Signature

t Gee-political CA

Signature

Cardholder CA Merchant CA Signature Signature

APG CA Signature

Cardholder Signature

‘igure 3: SET CA Architecture.

Merchant Signature

Merchant key Exchange

AGP AGP key Signature Exchange



The SET CA architecture is a hierarchy very much aligned with existing credit and debit card models and is depicted in Figure 3.

The design of SET accommodates the possibility of many brands (such as Visa, Mastercard and Europay). However, rather than require that users of SET store an authenticated public key for each and every brand (as per EMV), SET has extended the traditional card payments model and introduced a ‘Root CA’. The Root CA., certifies brand public keys so that users need only store a ‘trusted’ copy of the Root public key (self-signed) certificate. (The Geo-political CA is an optional level in the CA hierarchy and is implemented at the discretion of each brand.)

SET participants have certificates for signing and certificates for encryption, both based upon the basic X.509 certificate. Issuer names and Subject names have the following components:

?? countryName

?? OrganizationName

?? organizationalUnitName

?? commonName

where in cardholder certificates the commonName is a unique cardholder ID formed from the SHA-1 hash of the PAN, the card expiry date and a pseudo-random number established between the issuer and cardholder.

Definition of SET Private Extensions

SET uses the X.509 Version 3 extensions and also some SET ‘private extensions’ (see Table 4).

SET uses the Public Key Cryptography Standards (PKCS) for representing the cryptographic parameters and for message encapsulation. The default public key algorithm for use in SET is RSA with key lengths depending on the category of certificate holder.

6. Conclusions

The information needed in a certificate depends very much on the application in which it is to be used. This article has focused only on the type of information contained in a certificate and only on a few payment systems. There are many more issues surrounding public key certificates than have been explored in this article: public key infrastructures, certificate classes, secure

i__ Table 4: De@ition of SET Private Extensions.



E-mail, CRL management and attribute certificates (these are certificates that do not contain public keys but do reference a public key certificate), to name but a few.

Further information

Additional information relating to S.W.I.F.T. and CHARS can be found in

“Security for Computer Networks 2nd Edition”, by Davies and Price (published by John Wiley and Sons) and the specifications for EMV and SET can be found at the Visa and Mastercard Internet Web sites. An ever increasing wealth of information on digital certificates and related subjects can be found by searching the Internet.

List of Acronyms

CA Certification Authority

CHARS Clearing House Automated Payment System

CRL Certificate Revocation List

EMV

IC

IEC

IS0

ITU

PAN

PO!3

RSA

RTGS Real-Time Gross Settlement

SET Secure Electronic Transaction, protocol specification for making card payments over the Internet

Europay Mastercard Visa, specification for chip card payments at PO!3

Integrated Circuit

International Electrotechnical Commission

International Organization

Standards

International Telecommunication Union

Primary Account Number

Point-of-Sale

Rivest Shamir Adleman, Public Key Cryptosystem


Documents

Digital certificates and payment systems