feature

14

The low end of the PKI market isrepresented by B2C communicationcharacterized by credit card transactionsusing SSL-enabled Web browser andserver. The high end is where true E-business is performed between tradingpartners and is characterized by the use ofDirectories and certificate revocationmechanisms.

This article examines the technologyrequirements for each type of market.

Certification Authority

All PKIs require a Root CertificateAuthority (CA), which digitally signs asupplied public key and creates an X.509certificate. The signature process isperformed using the Root CA’s private keyand verified using the Root CA’s publickey. By securely distributing the Root CA’spublic key to any PKI component, it ispossible to verify that the certificate wasgenerated by the Root CA simply byverifying the certificate’s digital signature.A Subordinate CA or a user’s workstationwould normally generate the public keysupplied to the Root CA.

An optional component is asubordinate CA — optional, as smallPKIs only require a single CA.Nonetheless, many of the Internet onlineCAs, such as VeriSign, have subordinateCAs. A Subordinate CA has apublic/private key, with the public keyhaving been certified by the Root CA togenerate a Subordinate CA certificate. ARoot CA could have a number of

Subordinate CAs under it and aSubordinate CA could itself have anumber of Subordinate CAs under it.Subordinate CAs are the means by whicha ‘CA hierarchy’ is built. The complexityof this needs only to be understood bythose Enterprises wishing to build theirown PKI. Typically, neither the consumernor the supplier in a B2C environmentneeds be involved in this area.

An alternative to the hierarchicaltypology is cross-certification. Cross-certification involves two peer CAs thatcertify each other — but neither CAdominates the other. A certificateproduced by one of the peer CAs is calleda cross-certificate. Cross-certificates areused to validate a certificate chain to oneof the CA’s trusted root certificates. Ingeneral, hierarchical typologies suit andmatch a typical Enterprise’s organiz-ational structure, thus having the root CAat the corporate HQ and subordinateCAs at each international/countryaffiliate. A cross-certification typologytends to suit Extranet or trading partyrelationships where neither CAdominates the other. This type ofarrangement therefore tends only to beuseful in B2B environments.

Token

The user needs to store two items ofinformation securely on his/her desktop —the ‘trusted’ Root CA public key (used toverify certificates) and the user’s private key(used for cryptographic operations such as

digitally signing a transaction). Tokens areof two types — software and hardware —although, typically, hardware tokens aresmart cards. The token can be thought of asa secure repository for the aboveinformation. The token can also containadditional information on PKI policy, forinstance minimum key length and how tocommunicate with the ‘home’ CA.

Whether you require deployment ofSoft Tokens or smart cards is a balancebetween security (smart cards are moresecure) and cost. Of course a PKI couldhave a hybrid solution with those usersrequiring more security could be providedwith smart cards. Historically only B2Bhas used smart cards, but recentlyAmerican Express has launched their‘Amex Blue’ product that combines acredit card with smart card technology tobe used in B2C environments.

Directory

A Directory is used to store X.509certificates so they can be made generallyavailable. When a CA produces acertificate it is pushed to the CertificateRepository, the ‘key’ under which thecertificate is stored typically being thename of the owner of the public key inthe certificate. Applications within thePKI can automatically fetch certificateson a repository — so if A. Smith’scertificate is stored on the repository thenB. Brown could call up A. Smith’scertificate. Having a repository in a PKIwhere there is many-to-manycommunication occurring (like secure E-mail) is vital. The alternative is that B.Brown contacts A. Smith and asks him tosend his certificate to him, although thisis hardly a transparent automaticmechanism. The Certificate Repositorycan also be used to hold CertificateRevocation Lists (CRLs).

Directories are typically LDAP serversthat in large corporate environments useX.500 behind the LDAP interface.

Most B2C transactions use SSL and insuch situations the Directory is notrequired. However, Directories can beused to propagate certificate revocationinformation (see below).

Enabling E-CommerceThrough PKIJohn HughesEntegrity Solutions

john.hughes@entegrity.com

There are two main segments of the E-commerce marketplace: Business-to-Business(B2B) and the Business-to-Consumer (B2C). Whilst most transactions in bothsegments are protected using some type of Public Key Infrastructure (PKI)-basedtechnology [such as Secure Sockets Layer (SSL)], their trust infrastructures are builtupon completely different principles.

feature

15

Key generation andcertification

A PKI is an infrastructure that providesfull life-cycle management of key materialusing public key cryptography. Asexplained previously, public keys arewrapped up inside X.509 certificates.There are a variety of ways to generatepublic and private keys (a ‘key pair’) andthe X.509 certificates and to certify thepublic key:• Face-to-Face: The private/public key

pairs are generated at a RegistrationAuthority (RA), and then sent to theCA for certificate creation. The keysare placed on some type of Tokenand then securely provided to theuser by physical or electronic means.A Token could take the form of asmart card protected by a PIN and/ora second factor biometricauthentication. If it is a soft token,then typically the token is encryptedusing a PIN/Pass-phrase.

• Client generation: In this scheme thekeys are generated at the workstationand the public key sent to the CA forcertification. Submission of thecertification request is normallyperformed using HTTP, whichtransports the actual certificationrequest. Whilst the response willusually be obtained via HTTP, anintermediate E-mail step is verycommon. The identity of the usercreating the key pair has to beidentified to the CA, which should beauthenticated by one of twoapproaches:

• Back-end validation is the mostcommon approach and used by CAsthat do not support the issuing ofTokens. When the CA receives acertification request it will validate,manually or automatically, theidentity of the public key owneragainst a database of values. Theidentity information provided couldinclude details of the user notpublicly known, e.g. mother’smaiden name or date of birth. Thisinformation is then checked against

a database, perhaps generated froma human resources database. Analternative approach is for the CAoperator to manually supply theuser with a secret pass-phrase that issupplied along with the identityduring the certification request.This pass-phrase can then bevalidated by the CA.

• Tokens. For those products thatimplement a token-issuing scheme,the user’s identity is placed withinthe token. The token can alsocontain a secret pass-phrase that isautomatically passed to the CAduring the certification request. Thesecret pass-phrase can be derivedfrom some unique information inthe token and permit the CA toidentify and authenticate the user ofthe certification request. Thisapproach does not require a back-end database. Of course there is a third alternative— that of no authentication. In thiscase the supplied user’s identity isnot verified and any name can besupplied. Therefore the certificaterequestor could masquerade asanyone.

• Split Keys: It is possible to combineboth the face-to-face and clientschemes to produce a ‘split-key’scheme. In this case, one set of keys isgenerated at the client for a particularset of purposes and another setgenerated at the CA. Normally splitkeys will require some sort of token-issuing scheme. The split-key approachis usually the preferred architecture forEnterprises. It permits the key pairused to support confidentiality services(i.e. encryption) which are generatedand backed-up at the CA, with theability to recover a key should adocument require decryption if theuser loses the key (or changes affiliationor is ‘run over by a bus’). Theauthentication keys are then generatedat the client workstation, which thensupports the non-repudiation case byonly having one copy of a signing key— whose safe keeping is entrusted withthe end-user.

B2C usually only involves client keygeneration with no-authentication —that is, the user’s certificate is basicallyworthless. The B2C Web server, however,would normally have a certificate wherethe server identity has been authent-

icated. Having clients with no clientidentity authentication could be classifiedas weak-B2C. The typical credit-card SSLtransaction is secured by a combinationof the credit card company taking the riskand the credit card details sent by the userbeing validated by the goods supplier(although this is not always the case).There are some B2C situations, but notmany, when the client certificates havebeen generated following someauthentication, in which case this isstrong-B2C.

B2B will always require identityauthentication for certificate generation,as the credit card companies are nottaking the risk. If an enterprise isdeploying secure E-mail, then theynormally would use a split-key scheme toenable key recovery.

Revocation mechanism

Certificate Revocation Lists (CRLs) arenot the only technique available todetermine whether a certificate is stillvalid and has not been revoked. A newstandard and technology called OnlineCertificate Status Protocol (OCSP) hasbeen developed and OCSP-enabledproducts provide the ability to requeststatus information from a ValidationServer (i.e. an OCSP responder) on agiven certificate. This can provide nearreal-time certificate status information.CRLs by their very nature produce a time

“Cross-certificates are usedto validate a certificatechain to one of the CA’strusted root certificates”

“The token can be thoughtof as a secure repository for

the above information”

feature

16

lag between a CRL being published and itbeing fetched. CRL update periods ofbetween one day to one week are notuncommon. Although performance andscalability comparisons between CRLsand OCSP are hard to come by, it isreasonable to assume that bothtechnologies will co-exist and individualenterprises can decide which one suitstheir business model. As a means forcomparing CRLs and OCSP, imagine thetechniques used for checking credit cards.Historically, lists of stolen credit cardnumbers were supplied to a shop. Whenaccepting a card, the shop assistant wouldensure that the card number was not onthe list. This is the equivalent of the CRLmechanism. What is more common nowis for the assistant to swipe the cardthrough a reader and as part of thetransaction the status of the card ischecked online — the equivalent ofOCSP.

The main areas that typicallydistinguish B2B and B2C are that the

latter does not support RevocationMechanisms or Certificate Repositories.

Applications

To date, B2C transactions have beenalmost totally based on Web technologyusing SSL to provide some limitedsecurity functions. SSL providesconfidentiality, integrity andauthentication security, but in a situationwhere no authenticated certificates arebeing used, the authentication service isuseless (as explained previously). SecureE-mail is not deployed in the B2Cenvironment currently, although there is agrowing demand. However, withoutaccess to global directories there willalways be a usability problem.

B2B transactions will use either SSL orsecure E-mail. Increasingly there are newapproaches to achieve B2B over andabove the usual Web purchasing model.These models permit online auctioningand catalogue purchasing. Systems to

achieve this are being developed now andsome deployments have already started.They all use SSL and/or secure E-mail,but the applications are moresophisticated in the way they use theunderlying security technology. Oneapproach is for the SSL to be used tocarry digitally signed transactions, whichuse a sub-set of the technology used in

secure E-mail. In this case the goodssupplier can verify that the individualand/or the organization did actually sendthe transaction. Identrus is one suchorganization that is developing anddeploying a system to use this technologyfor its customers, which include many ofthe leading financial institutions in theworld (see www.indentrus.com for moredetails).

Conclusion

This analysis of the security buildingblocks for B2B and B2C has shown thatB2C actually only requires support for alightweight PKI. However, B2B andintra-enterprise environments require afull PKI. Table 1 summarizes the featuresand requirements of B2B and B2C E-commerce.

About the author

John Hughes, Director of World WidePartner Development at EntegritySolutions, has over 22 years experience in ITsecurity. Since joining Entegrity in 1997,John has been responsible for developing thePKI marketplace in Europe. He has boththeoretical and practical knowledge of PKIand cryptography, regularly developingsolutions for clients using EntegritySolutions technology. John can be contactedvia E-mail at john.hughes@entegrity.com.

Feature B2B B2CCertificate Authorities 4 4

Registration Authority 4 7

Hierarchical Topology 4 4

Cross-certification Topology 4 7

Smart card Token 4 Ô

Directories 4 7

Face-to-face registration 4 7

Client Generation 4 4

Client identity authentication 4 7

Server identity authentication 4 4

Split Keys 4 7

Key backup 4 7

Certificate Revocation Lists (CRL) 4 7

Online Certificate Status Protocol (OCSP) 4 7

SSL 4 4

Secure E-mail 4 Ô

Digital Signature transactions 4 7

Key: 4 Used extensively 7 Not a requirementÔ Emerging requirement

Table 1: The features and requirements of B2B and B2C E-commerce.

“SSL providesconfidentiality, integrity

and authenticationsecurity”