From SET to PSET The Pseudonymous Secure Electronic Transaction Protocol

Size: px
Start display at page:

Download "From SET to PSET The Pseudonymous Secure Electronic Transaction Protocol"

Transcription

1 From SET to PSET The Pseudonymous Secure Electronic Transaction Protocol Marc Rennhard, Sandro Rafaeli and Laurent Mathy Swiss Federal Institute of Technology, Computer Engineering and Networks Laboratory; Zurich, Switzerland Lancaster University, Faculty of Applied Sciences; Lancaster, UK Technical Report TIK-Nr. 117 August, 2001 Abstract Credit cards have been the dominant payment method in e-commerce during the past years and it is not expected that this is going to change soon. However, credit card payments as used today are not suited for anonymous or pseudonymous payments. Credit card payments disclose the identity of a customer to the merchant and the issuer of the credit card knows exactly where the customer makes payments. The Secure Electronic Transaction (SET) protocol makes credit card payments over the Internet more secure, but it does not much to protect the privacy of the customer. In this report, we present the Pseudonymous Secure Electronic Transaction (PSET) protocol. PSET is an extension of SET and enables pseudonymous credit card payments over the Internet. Pseudonymous payments mean that none of the involved parties in the payment process can learn the identities of both the customer and the merchant at the same time. This is achieved by distributing the knowledge of the whole transaction among the involved parties. On the other hand, PSET guarantees that it is not possible for any of the involved parties to cheat and that it is possible to unambiguously resolve the identity of a pseudonymous customer in case of a dispute. Keywords: anonymity, pseudonymity, credit card payments, secure electronic transaction, e- commerce 1 Introduction This document describes the Pseudonymous Secure Electronic Transaction (PSET) protocol. The PSET protocol is an extension to the Secure Electronic Transaction Protocol (SET) and its goal is to provide secure and pseudonymous credit card payments over the Internet. Before we start to describe PSET, we describe the SET protocol. The SET protocol allows for secure and private credit card payments over the Internet. The complete specification of SET can be found in three books [4, 5, 6], which together consist of approximately 1000 pages. Since the whole standard is quite complex, we first explain SET using only the most important fields of the protocol. However, we try to make sure that the security-relevant fields are included. This should make it possible to understand the main concepts, ideas, and security mechanisms used in SET, and provides a good starting point for the reader to do a more detailed analysis of the protocol on his own. We also explain why SET is secure against various kinds of attacks.

2 In a second step, we extend SET such that it allows for pseudonymous payments. One main goal of PSET is that it should follow SET wherever this is possible. We also explain why PSET is not less secure than SET and why it indeed provides pseudonymous credit card payments. We have tried to follow the same terminology and notation as the one used in the SET books. 2 Participants in SET The participants in SET are the following: The Issuer is usually a financial institution and issues credit cards. The credit cards are exactly the same credit cards as we use today. In addition, the issuer issues a Digital Certificate for cardholders, which enables them to authenticate themselves. The certificate does not contain information identifying the cardholder s credit card. The Cardholder is the holder of a credit card and a digital certificate. The Merchant sells goods or services to the cardholder. A merchant that accepts credit cards must have a relationship with an acquirer. The Acquirer is the financial institution that establishes an account with the merchant and processes credit card payment authorizations and the payments. The acquirer transfers money to the merchant and is reimbursed by the issuer. The Payment Gateway is located between the merchant and the acquirer. The payment gateway interfaces between SET and the existing payment networks for authorization and payment functions. This means that the merchant is usually talking to the acquirer s payment gateway and not to the acquirer directly. It is important to realize that the SET protocol is carried out by the cardholder, the merchant, and the payment gateway. The credit card payment from payment gateway via acquirer, payment network, and issuer is done as it is today in normal credit card payments and is not standardized by SET. Figure 1 illustrates the participants. 3 SET Public-Key Infrastructure SET makes use of public-key cryptography to assure its security. The cardholder, merchant, and payment gateway are involved in handling the SET protocol. Each of them owns one or more certificates and keypairs. Figure 2 illustrates the public-key infrastructure of SET. The root certification authority (CA) is a SET-wide trusted third-party and issues certificates for brand certification authorities, such as Visa, Mastercard or American Express. Each brand CA can then issue certificates for regional certification authorities. In figure 2, we have two regional Visa CAs, one for Europe and one for Northern America. The regional CAs again issue certificates for cardholder certification authorities. A cardholder CA is associated to a company that issues credit cards. These cardholder CAs issue SET certificates for their cardholders. The regional CAs not only certify certification authorities for cardholders, but also those for merchants and payment gateways. This means that not only the cardholders, but also the merchants and the payment gateways certificates are bound to a specific credit card brand. Therefore, merchants and payment gateways have one pair of certificates (one for signing and one for key-exchange) for each credit card brand they accept. 2

3 PInitReq (1) PInitRes (2) PReq (3) PRes (6) Cardholder Merchant $ Issuer Internet AuthReq (4) AuthRes (5) Payment Network $ Acquirer Payment Gateway Figure 1: Participants in SET Root CA Visa CA Mastercard CA Brand CAs Visa Europe CA Visa North America CA Geo-political CAs Visa Card Issuer CA Visa Merchant CA Visa Payment Gateway CA Visa Cardholder Certificate Visa Merchant Certificate Visa Payment Gateway Certificate Figure 2: SET Public-Key Infrastructure in SET Table 1 lists the certificates that are used in the SET protocol. Cert identifies the certificate for signing of party X, whereas PrK and PuK identify the corresponding private and public keys. Similarly, Cert identifies the certificate for key-exchange of party X, whereas PrK and PuK identify the corresponding private and public keys. Note that the<y cardholder has one such key-pair with corresponding certificate per credit card he owns. The merchant and the payment gateway have two key-pairs with corresponding certificates for each brand of credit card they process. 3

4 Table 1: Certificates and Keys Participant Certificate/Keys Certificate/Keys for Signing for Key-Exchange Cardholder Cert ; (per credit card) PrK, PuK Merchant Cert ; Cert ; (per credit card brand) PrK, PuK PrK, PuK Payment Gateway Cert ; Cert ; (per credit card brand) PrK, PuK PrK, PuK 4 Protocol Phases in SET The SET protocol consists of several phases; they are illustrated in figure When the cardholder has finished shopping and wants to initiate a SET payment, he sends a Initiate Request (PInitReq) message to the merchant. 2. The merchant answers with a Initiate Response (PInitRes) message. 3. The actual payment process starts with the cardholder sending a Purchase Request (PReq) message to the merchant. 4. The merchant initiates payment authorization by sending an Authorization Request (AuthReq) message to the payment gateway. 5. When the payment gateway has completed payment authorization via the acquirer, it replies with an Authorization Response (AuthRes) message to the merchant. 6. The merchant sends a Purchase Response (PRes) message to the cardholder. Since we are mainly concerned with the process of the payment and its authorization, we will look at phases 1 4 in detail. 4.1 Initiate Request (PInitReq) Before this phase begins, the cardholder has completed selecting goods and gets an Order Description (OD) presented by the merchant. This description is basically a list of selected goods and their prices, but the format of this OD is not standardized by SET. Note also that presenting the OD is not part of the SET protocol. Table 2 specifies the order description. OD Table 2: The Order Description (OD) The order description, generated by the merchant for the user Eventually, the cardholder informs the merchant that he wants to initiate a payment. This is done by sending an PInitReq message to the merchant. The message includes a BrandID specifying the brand of credit card the user plans to use. Table 3 describes the PInitReq message. This message is sent to the merchant. When receiving the message, the merchant does the following: 1. Examines the BrandID and checks if he accepts this brand of credit card. 4

5 Table 3: The Initiate Request message (PInitReq) PInitReq BrandID BrandID An ID specifying the brand of credit card to use 4.2 Initiate Response (PInitRes) In this phase, the merchant answers the cardholder s request. The merchant selects a unique Transaction ID (TransID) which is used during the whole transaction for identification purposes. The merchant also sends his certificate for signing and the payment gateway s key-exchange certificate. The message is signed by the merchant. Both certificates have to correspond to the credit card brand specified by the user in his PInitReq message (table 3). Table 4 specifies the PInitRes message. Table 4: The Initiate Response message (PInitRes) PInitRes Sign (TransID), Cert, Cert TransID Cert An ID specifying the whole transaction The merchant s certificate for signing (table 1) corresponding to the specified credit card brand by the cardholder (table 3) Cert The payment gateway s key-exchange certificate (table 1) corresponding to the specified credit card brand by the cardholder (table 3) When the cardholder receives this message, he does the following: 1. Checks if the merchant s certificate for signing (Cert ) is valid, and if it is indeed the merchant s certificate, and if it is the correct certificate for the specified credit card brand. 2. Checks if the payment gateway s certificate for key-exchange (Cert ) is valid and if it is the correct certificate for the specified credit card brand. 3. Verifies the merchant s signature. If the signature can successfully be verified, then the cardholder can be sure that the message was indeed generated by the merchant. When this phase is completed, the cardholder starts the actual payment process. 4.3 Purchase Request (PReq) During this phase, the cardholder generates the necessary information for the merchant and the payment gateway. The information consists of two parts, one is for the merchant and the other is for the payment gateway. In the first step, the Order Information Data (OIData) (table 6) is created, which contains the information for the merchant. OIData does not contain a direct link to the OD (table 2), but contains a hashed value, the Hashed Order Description (HOD), as a reference to the OD. HOD is described in table 5. Table 5: The Hashed Order Description (HOD) HOD Hash(OD, PurchAmt, ODSalt) OD The order information (table 2) PurchAmt The amount of the transaction ODSalt A nonce to prevent dictionary attacks on HOD 5

6 Table 6: The Order Information Data (OIData) OIData TransID, HOD, ODSalt, BrandID TransID The ID identifying the whole transaction HOD The hash on the OD (table 5) ODSalt The salt used in HOD (table 5) BrandID An ID specifying the brand of credit card to use HOD is now used in OIData. Table 6 describes the information included in OIData. The customer also computes a hash of OIData, Hashed Order Information Data (HOIData), as this is used later. Table 7 describes HOIData. Table 7: The Hashed Order Information Data (HOIData) HOIData Hash(OIData) OIData The order information data (table 6) Similarly, the cardholder generates the Payment Information Data (PIData) for the payment gateway. Table 8 defines PIData. PIData Table 8: The Payment Information Data (PIData) TransID, HOD, PurchAmt, MerchantID, CC TransID The ID identifying the whole transaction HOD The hash on the OD (table 5) PurchAmt The amount of the transaction MerchantID An ID identifying the merchant (extracted from Cert ) CC Data identifying the cardholder s credit card (such as the credit card number) The customer also computes a hash on PIData, the Hashed Payment Information Data (HPIData), as this is used later. Table 9 describes HPIData. Table 9: The Hashed Payment Information Data (HPIData) HPIData Hash(PIData) PIData The payment information data (table 8) To link the OIData and the PIData, the cardholder computes a Dual Signature (DS) over OIData and PIData. The dual signature is basically a signature over the hash of the concatenation of HOIData (table 7) and HPIData (table 9). Table 10 describes how the dual signature is defined. Table 10: The Dual Signature (DS) DS Sign (Hash(HOIData, HPIData)) HOIData The hashed order information data (table 7) HPIData The hashed payment information data (table 9) It is convenient to summarize all the information that the merchant will forward to the payment gateway later as the Payment Information (PI). This is described in table 11. Note that PI contains PIData, but PIData is encrypted for the payment gateway. This means that the merchant does not see 6

7 the cardholder s credit card (included in OIData), which is a big advantage over conventional credit card payments in the Internet. Table 11: The Payment Information (PI) PI E (PIData, HOIData), E (K ), DS E (PIData, HOIData) The PIData (table 8) plus HOIData (table 7), encrypted with a one-time symmetric key K E (K ) The one-time symmetric key K, encrypted with the key-exchange public key PuK of the payment gateway DS The dual signature (table 10) The customer is now ready to generate the whole Purchase Request message. Table 12 defines how PReq is constructed. Table 12: The Purchase Request message (PReq) PReq OIData, HPIData, PI, Cert OIData The order information data (table 6) HPIData The hashed payment information data (table 9) PI The payment information for the payment gateway (table 11) Cert The customer s certificate for signing This message is sent to the merchant. When the merchant receives PReq, he performs the following steps: 1. Checks if the cardholder s certificate for signing (Cert ) is valid. 2. Applies the cardholder s public key on the dual signature DS (contained in PI), and compares the result with the value Hash(Hash(OIData), HPIData) (using OIData and HPIData from PReq). If the two values are equal, then the signature was made by the customer and OIData has not been changed in transit. 3. Checks if TransID in OIData corresponds to a requested transaction id. If this test is OK, then the merchant knows that this payment corresponds to a previously initiated payment. 4. Checks if BrandID in the cardholder s certificate corresponds to BrandID specified in PInitReq (table 3) and OIData. 5. Compares HOD with a self-generated version based on the locally stored OD and PurchAmt, and ODSalt from OIData. If this test is OK, then the merchant knows that the cardholder is indeed paying for the order they agreed on earlier (specified in OD), and that he is paying the correct amount. Note that although the merchant now knows that the cardholder indeed generated an authentic and valid OIData that belongs to a previously specified OD, the merchant has no idea if the encrypted payment information for the payment gateway contains valid data. When discussing the validation at the payment gateway, we will see that the dual signature indeed binds the payment to the order, but this can only be verified by the payment gateway. For the merchant, it is a pure authentication (and integrity check) of the cardholder s order. 7

8 4.4 Authentication Request (AuthReq) In this step, the merchant asks the payment gateway to validate the payment. Basically, the merchant forwards the payment information (PI) received from the cardholder in the PReq message, but the merchant also includes an Authorization Request Payload (AuthReqPayload), as described in table 13. Table 13: The Authorization Request Payload (AuthReqPayload) AuthReqPayload TransID, AuthReqAmt, HOIData, HOD TransID The ID identifying the whole transaction AuthReqAmt The amount the merchant wants to charge on the cardholder s credit card HOIData The hash on OIData (table 6); independently computed by the merchant HOD The hash on the OD (table 2); independently computed by the merchant This AuthReqPayload is then sent to the payment gateway in an Authorization Request (AuthReq) message, among other information. This is described in table 14. Table 14: The Authorization Request message (AuthReq) AuthReq E (Sign (AuthReqPayload)), E (K ), PI, Cert, Cert E (Sign ( The signed AuthReqPayload (table 13), AuthReqPayload)) encrypted with a one-time symmetric key K E (K ) The one-time symmetric key K, encrypted with the key-exchange public key PuK of the payment gateway PI The payment information from the cardholder (table 11) Cert The cardholder s certificate for signing Cert The merchant s certificate for signing When the payment gateway receives AuthReq, it performs the following steps: 1. Checks if the cardholder s certificate for signing (Cert ) is valid. 2. Checks if the merchant s certificate for signing (Cert ) is valid. 3. Extracts the one-time symmetric key K and uses it to decrypt the AuthReqPayload. 4. Checks if the merchant s signature on AuthReqPayload is authentic. 5. Extracts the one-time symmetric key K in PI and uses it to extract PIData and HOIData from PI. 6. Checks if TransID in AuthReqPayload corresponds to TransID in PIData. If they are the same, then the cardholder is indeed paying for the transaction the merchant requests. The payment gateway checks also that the AuthReqAmt in AuthReqPayload is the same as the PurchAmt in PIData. This assures that the cardholder pays enough and that the merchant doesn t charge too much. 8

9 7. Applies the cardholder s public key on the dual signature DS (contained in PI), and compares the result with the value Hash(HOIData, Hash(PIData)) (using HOIData and PIData contained in PI). If the two values are equal, then the signature was made by the cardholder and PIData has not been changed in transit. 8. Compares the HOIData received from the cardholder (in PI) and from the merchant (in AuthReq- Payload). This assures that the payment belongs indeed to order information sent from the cardholder to the merchant. Note that if the merchant checks the dual signature and the signature is authentic, then it is not possible for the cardholder to supply a different PIData/HOIData pair that matches the dual signature. Therefore, this additional check by the payment gateway assures that the link of the order to the payment is guaranteed even when the merchant does not check the dual signature or the dual signature is not used. 9. Compares the HOD received from the cardholder (in PI) and from the merchant (in AuthReqPayload). This is needed if the merchant cannot verify the HOD in OIData (that could happen in the case of an out of band receipt of relevant data by the merchant [5]). 10. Checks if the MerchantID in PIData is the same as the MerchantID in the merchant s certificate for signing. This guarantees that merchants cannot use payment informations intended for another merchant. 11. The payment gateway uses CC and PurchAmt from PI to authorize payment through existing payment card financial networks. 4.5 Authentication Response (AuthRes) This message is sent from the payment gateway to the merchant. It contains the TransID and information about the authorization of the payment. It also contains a capture token which can be used by the merchant during payment capture. The message is signed and encrypted for the merchant. 4.6 Purchase Response (PRes) This message is sent from the merchant to the cardholder to inform him whether the purchase has been authorized and is therefore completed or not. The message contains the TransID and is signed by the merchant. 5 Security Analysis A digital payment system has to be secure against various kinds of attacks. We only look at the most important ones here, which should make the need for transactions IDs and dual signatures clear. We assume that the cryptographic mechanisms are secure in the sense that it is not possible to forge a signature, find the input to a hash function from its output, or find out a one-time symmetric key for encryption. In addition, we assume that all certificates are correctly verified and that none of the private keys has been compromised. SET is a very complicated protocol. Parts of this complexity stem from the fact that SET can operate in different modes. For instance, SET should work securely even if the dual signature is not used. That s the reason why the merchant adds it s own copy of HOIData in the AuthReqPayload (table 13). Another example that increases SET s complexity is the inclusion of HOD in the AuthReqPayload (table 13), which guarantees that the protocol is secure even if the merchant is not able to verify HOD in OIData (table 6). All these redundant security checks make it quite difficult to explain why certain properties of SET add to the security in what way, since there seems to be always another mechanism that guarantees SET s security if the first one is compromised or not used. 9

10 5.1 Replay Attacks In a replay attack, the attacker (for instance the merchant) simply replays a previous sequence of messages. Since a message uses a unique TransID (where the TransID consists of several parts, among others a timestamp and a globally unique identifier XID ([5], pages 70, 267)). Therefore, the payment gateway will block any attempt to reuse messages of previously completed transactions. 5.2 Substitution Attacks By the Merchant A possible attack for a merchant could be to send the same TransID to two different customers, A and B, when they want to start their SET payments. In addition, assume that A has selected goods for 10$ and B for 20$, and both use the same brand of credit card. The merchant gets the PReq (table 12) messages of both customers. The merchant now tries to satisfy A s order (for 10$), but uses B s PI (for 20$) in A s AuthReq message. Now if the dual signature were not used and the cardholder would sign OIData and PIData separately (where the signed OIData would be for the merchant and the signed PIData would be for the payment gateway), then this attack would indeed be possible, since the order would not be bound to the payment in any way. The payment gateway would have no way to tell if a particular payment belonged to a certain order, since all the payment gateway gets is a payment information that is signed by B, contains a previously unused transaction id, and has the correct merchant id. Of course, B would eventually complain since her credit card was charged but she never received the goods she ordered, but B has no proof to show what goods she actually ordered, since her PI is not bound in any way to her order. Indeed, this would offer the merchant lots of possibilities to cheat. A customer buys a car for $, and delivers the PI via SET to the merchant. The merchant claims the money but never delivers the car. The cardholder would complain, but cannot prove that the payment is for a car. The merchant could simply say that the customer donated the money to the shop. Surprisingly, SET would be secure against this attack even if it worked as described above (without the dual signature). The trick is that the payment information still contains a reference to the order the cardholder placed. This is guaranteed by the HOD field in the PIData (table 8). The cardholder can always provide the valid input to the hashed order description, which means that there is a link between the order description and the payment information. Note that the SET specifications say that the HOD in PIData is used to protect the merchant. If the merchant is not able to check the HOD it received by the cardholder, he can still be sure that the cardholder cannot cheat by placing a fake HOD in PIData. This is the reason why the merchant adds the HOD he expects from the cardholder in the AuthReqPayload. So if we assume that HOD is only in PIData to protect the merchant, then the attack described above is indeed possible (still assuming that the dual signature were not used). The dual signature thwarts this kind of attack: the customer binds his payment to his order by signing the hashed order and payment information together. Note that it is still possible for the merchant to carry out the attack described above. In general, it is not possible for the payment gateway to find out or control if the merchant is going to deliver the right goods to the cardholder, since the payment gateway never learns the details of the order, but only its total amount. However, in the case of a dispute, the cardholder can deliver the necessary information and together with the payment information (table 11) prove what his exact order was. To do so, the cardholder provides the inputs to the hashed order description (HOD, table 5) and to the hashed order information data (HOIData, table 7). The properties of the oneway hash function used to compute HOIData and HOD makes the generation of alternative, meaningful inputs (especially OD) that hash to the same values infeasible. From this point of view, the payment information (PI) is like a contract that binds the order to the payment. 10

11 5.2.2 By the Cardholder For the cardholder, it is also not possible to make a substitution attack. If he uses a HOIData in PI which is not the hash of OIData, then this will be noticed by either the merchant or the payment gateway, since there is only one dual signature. And it is infeasible to construct two different OIData which both hash to the same HOIData. If we assume again that the SET protocol worked as described above (without the dual signature), then the attack would still not be possible since the merchant supplies his version of the expected HOD in the AuthReqPayload. Here we assume that the payment gateway checks that the two HODs one in PIData from the cardholder and the other in AuthReqPayload from the merchant are indeed the same, as the payment gateway is obliged to do according to the SET protocol. To summarize, SET greatly increases the security of credit card payments in the Internet. It does not seem possible to cheat for any of the involved parties without compromising someone else s private key and therefore being able to forge that party s digital signature. However, we should also note that due to SET s property to function securely even when the dual signature is not used, SET s complexity is increased. It becomes even questionable why the dual signature is needed if the protocol is supposed to work correctly without it. 6 The Reason for the Dual Signature Since the dual signature is a very important key concept, we summarize here why it is needed. 1. When the dual signature is constructed, it gets the hash of the concatenated hashes of OIData and PIData as inputs. Because of the properties of secure hashes, it is not feasible to find other meaningful OIData or/and PIData that hash to the same value. 2. Since the cardholder signs the hash, it is not possible for anybody to find an input the signature of which has the same value. Therefore, there exists only one meaningful OIData/PIData pair as the input for a given dual signature. In addition, it is not possible to forge somebody else s signature, which means that the dual signature unambiguously binds an OIData/PIData pair to a cardholder. 3. When the merchant validates the dual signature, then he can be sure that the signature was indeed made by the intended cardholder. In addition, he checks if the OIData that was used as the input to the dual signature corresponds indeed to the right order by comparing the data supplied by the cardholder with a local copy of the order description. 4. The merchant cannot check if the PIData in the dual signature is valid; this can only be done later by the payment gateway. 5. The payment gateway also checks the dual signature for its correctness. if it is valid, then the payment gateway can be sure about the authenticity and integrity of the dual signature. Since the merchant has checked that the payment belongs to the right order and the payment gateway has checked that the payment information is valid (and also that the payment amounts supplied by the cardholder and merchant both make sense), there is no way for the cardholder or the merchant to cheat. 6. In an earlier version of SET, there were two dual signatures, one for the merchant and one for the payment gateway. This would have made it possible for the cardholder to cheat, in the sense that he could send a valid OIData to the merchant (with valid dual signature), but the HOIData of another OIData (with more valuable goods than in the OIData for the merchant) to the payment gateway. Both the merchant and the payment gateway would accept the dual signature, and the cardholder could claim the more valuable goods (specified by HOIData for the payment gateway). Using only 11

12 one copy of the dual signature makes this attack impossible. However, not even that attack would have been possible since there is another security mechanism that guarantees the security of SET even when dual signatures are not used. This is described in the next item. 7. This additional security mechanism requires the merchant to include his own copy of HOIData in the AuthReq message, and the payment gateway checks if it corresponds to the one submitted by the cardholder. Now if the merchant checks the dual signature correctly, this is a redundant check by the payment gateway. But if the merchant does not check the dual signature or if the dual signature is not used, then checking the two HOIData prevents the above mentioned attack by the cardholder. 8. A similar additional security mechanism is used by the merchant in the sense that he also sends an own computed version of HOD in the AuthReq message. This too would not be required if the merchant checked the HOD submitted by the cardholder. But if the merchant is not able to do that, then this prevents the cardholder from submitting an invalid HOD to he payment gateway. To summarize dual signature prevents the cardholder and merchant from cheating. Most importantly, the dual signature binds the order to the payment. The cardholder is not able to generate valid payment information for other goods than the ones he ordered, and the merchant cannot claim that the payment is for other goods than those ordered by the customer. In addition, even if the dual signature is not checked by the merchant, there are mechanisms in SET to prevent cheating, as described at items 7 and 8. 7 Privacy Analysis of SET Despite adding security to credit card payments in the Internet, SET also protects the cardholder s privacy to a certain extent. SET achieves that by making sure that each of the involved parties knows only as much as is needed to perform the credit card payment and its validation correctly. Today, credit card payments in the Internet are usually carried out using a server-side authenticated and secure connection based on the secure sockets layer (SSL)-protocol. This protects the details of the cardholder s credit card (e.g. the credit card number) from malicious third parties, but the merchant still learns the credit card number. If we compare SET to credit card payments as they are performed today in the Internet, then SET adds the following to protect the cardholder s privacy: The merchant never learns details about the cardholder s credit card (e.g. the credit card number). This reduces the risk of fraud by the merchant. The payment gateway (which is usually the same instance as the acquirer) does not learn the details of the cardholder s order. To summarize, SET enhances the privacy of the cardholder by making sure that none of the involved parties learns everything about a whole transaction. This is not the case in today s Internet, where the merchant learns everything. SET guarantees this by splitting the knowledge between the merchant and the payment gateway. If these two parties collude, then they know exactly as much as the merchant does in today s Internet. However, SET does not really add much to protect the cardholder s privacy, since the merchant still knows exactly what each user has bought, and different merchants are easily able to combine their data to construct customer profiles. Particularly, SET does not give the customer the slightest bit of anonymity. 12

13 8 Pseudonymous SET (PSET) We now extend SET such that it provides pseudonymous credit card payments. The goal is to enable this by extending SET as little as possible. PSET requires a new participant, which is called the Pseudonymous Credit Card Provider (PCCP). The idea of the PCCP is to provide Pseudonymous Credit Cards (PCC) that cannot be easily linked to the cardholder s real identity. These PCCs look exactly like a normal credit card, except that they do not contain a link to the cardholder s real identity such as his name. A user that wishes to obtain a PCC simply contacts a PCCP and asks it for a PCC and a certificate that can be used for signing in the PSET protocol. Note that the user does not have to authenticate himself to the PCCP. The PCCP issues the pseudonymous credit card and a certificate without knowing the real identity of the receiver. The PSET protocol guarantees that it is not possible to misuse the PCC, although the issuer of the PCC does not know the cardholder s identity. Since the PCC has to be obtained anonymously, the cardholder should not contact the PCCP directly via the Internet, but should use a technique that hides his identity from the PCCP [1, 3]. Since the PCCP issues pseudonymous credit cards without knowing the receiver, we have to make sure that the cardholder can only use this PCC when it is guaranteed that the payment can by unambiguously related to his real identity. The basic idea how this is achieved in PSET is that we assume that the owner of the PCC also has a normal credit card. When paying with the PCC, the cardholder not only includes payment information to charge his pseudonymous credit card, but also payment information to charge his real credit card. However, PSET must guarantee that none of the involved parties in the payment process ever learns who the real identity of the owner of the PCC is. The basic idea how this is achieved is that the PCCP pays the merchant and the issuer of the cardholder s real credit card pays the PCCP. So in the end it is still the issuer of the cardholder s real credit card that pays the merchant, but we use the PCCP in the middle to separate the knowledge to link the cardholder to his real credit card. 9 Participants in PSET The participants in SET are basically the ones described in section 9, but with some additions: The Issuer is usually a financial institution and issues credit cards. The credit cards are exactly the same credit cards as we use today. In addition, the issuer issues a Digital Certificate for cardholders, which enables them to authenticate themselves. The certificate does not contain information identifying the cardholder s credit card. The Cardholder is the holder of a credit card and a digital certificate, and a pseudonymous credit card with a digital certificate. This means that the cardholder has two credit cards with two certificates, but only one credit card is linked to his identity. The PCCP issues pseudonymous credit cards. The credit cards look like normal credit cards except that they cannot be linked to the cardholder. In addition, the PCCP issues a Digital Certificate for the cardholders, which enables them to authenticate themselves pseudonymously. Note that the PCCP plays basically the same role as the issuer in the sense that it issues credit cards. However, since the PCCP will never validate a payment with the PCC before the payment is validated with the cardholder s real credit card, there is no financial risk for the PCCP. This is a very important property of PSET. The Acquirer is the financial institution that establishes an account with the merchant and processes credit card payment authorizations and the payments. Note that we have now two acquirers. One is the acquirer of the merchant and the other is the acquirer of the PCCP. 13

14 Similarly, we have now two Payment Gateways, since we have two acquirers. The reason for them is the same as in SET, to interface between SET and the existing payment networks for authorization and payment functions. Note that the PCCP plays two roles: One is as an issuer of credit cards when talking to the merchant s acquirer. The other is as a merchant when talking to the payment gateway of it s acquirer. Figure 3 shows the participants in PSET. PInitReq (1) PInitRes (2) PReq (3) PRes (8) Cardholder Merchant Internet $ Acquirer (PCCP) Payment Gateway (PCCP) NestAuthReq (5) NestAuthRes (6) $ AuthReq (4) AuthRes (7) PCCP $ Payment Network $ Issuer Acquirer (M) Payment Gateway (M) Figure 3: Participants in PSET 10 PSET Public-Key Infrastructure Like SET, PSET makes use of public-key cryptography to assure its security. All involved parties possess one or more certificates and key-pairs. Figure 4 illustrates the public-key infrastructure of PSET. Basically, there is no difference to the SET public-key infrastructure in figure 2. We have simply added a PCCP brand CA, assuming that there is a dedicated credit card brand for pseudonymous credit cards. Like Visa or Mastercard, PCCP is a brand for a financial network that enables credit card payments. The Visa CA is the top-level CA for handling payments involving a Visa credit card, while the PCCP CA is the top-level CA for handling payments involving a pseudonymous credit card, or a PCC. Note that nothing prevents Visa, Mastercard, or any of the other brands to issue pseudonymous credit cards. But for clarity, we have added a new brand that issues the pseudonymous credit cards. Every financial institution that issues normal credit cards could then also issue pseudonymous credit cards. Another approach is that there are dedicated normal credit card issuers for a brand and dedicated pseudonymous credit card issuers for the same brand. PSET does not restrict who issues pseudonymous credit cards. All that PSET requires that the PCCPs are seamlessly integrated into the SET public-key infrastructure. Like in SET each of these parties in PSET owns one or more certificates and keys. Table 15 lists the certificates that are used in the PSET protocol. The semantics are the same as in table 1. 14

15 Root CA Visa CA Mastercard CA PCCP CA Brand CAs Visa Europe CA Visa North America CA PCCP North America CA PCCP Europe CA Geo-political CAs Visa Card Issuer CA Visa Merchant CA Visa Payment Gateway CA PCCP Card Issuer CA PCCP Merchant CA PCCP Payment Gateway CA Visa Cardholder Certificate Visa Merchant Certificate Visa Payment Gateway Certificate PCCP Cardholder Certificate PCCP Merchant Certificate PCCP Payment Gateway Certificate Figure 4: PSET Public-Key Infrastructure in PSET Table 15: Certificates and Keys Participant Certificate/Keys Certificate/Keys for Signing for Key-Exchange Cardholder s real Cert ; certificate PrK, PuK (per credit card) Cardholder s pseudonymous Cert ; certificate PrK, PuK (per pseudonymous credit card) Merchant Cert ; Cert ; (per credit card brand) PrK, PuK PrK, PuK Payment Gateway Cert ; Cert ; of Merchant PrK, PuK PrK, PuK (per credit card brand) PCCP Cert ; Cert ; (per credit card brand) PrK PuK PrK,, PuK Payment Gateway Cert ; Cert ; of PCCP PrK, PrK, (per credit card band) PuK PuK Note that the cardholder has now two sets of certificates and keys. The first corresponds to his real credit card, and when the cardholder is using this set, then we speak of the real certificate, real private key and real public key. The second set is associated with the pseudonymous credit card, and we speak of the pseudonymous certificate, pseudonymous private key and pseudonymous public key in this case. 11 Protocol Phases - PSET The PSET protocol phases are basically the same as in SET (section 4). However, since two credit cards are now involved, there are two authorization request and response phases instead of one. PSET consists of the following phases: 1. When the cardholder has finished shopping and wants to initiate a SET payment, he sends a Initiate Request (PInitReq) message to the merchant. 15

16 2. The merchant answers with a Initiate Response (PInitRes) message. 3. The actual payment process starts with the cardholder sending a Purchase Request (PReq) message to the merchant. 4. The merchant initiates payment authorization by sending an Authorization Request (AuthReq) message to the payment gateway. 5. This authorization is done via payment gateway, acquirer, and PCCP. When the PCCP gets the authorization request, it does not simply answer directly, but sends a Nested Authorization Request (NestAuthReq) to it s payment gateway. 6. When the payment gateway has completed payment authorization via the acquirer and the issuer, it replies with an Nested Authorization Response (NestAuthRes) message to the PCCP. 7. Since the PCCP can now be sure that it gets the money from the issuer, it authorizes the pseudonymous credit card payment back via the acquirer to the payment gateway, and the payment gateway replies with an Authorization Response (AuthRes) message to the merchant. 8. The merchant sends a Purchase Response (PRes) message to the cardholder Initiate Request (PInitReq) This phase works in exactly the same way as in SET (section 4.1). Note that the BrandID specified by the cardholder in the PInitReq message is now the one of the pseudonymous credit card (PCC). Therefore, we use a slightly different notation here, as illustrated in table 16. PInitReq BrandID Table 16: The Initiate Request message (PInitReq) in PSET BrandID An ID specifying the brand of the pseudonymous credit card to use This message is sent to the merchant where it is processed in the same way as in SET (section 4.1) Initiate Response (PInitRes) This phase works similar as described in section 4.2. Since there will be more than one payment gateway involved in PSET, we are slightly changing the notation in the PInitRes message, as table 17 illustrates. Table 17: The Initiate Response message (PInitRes) PInitRes Sign (TransID), Cert, Cert TransID Cert An ID specifying the whole transaction The merchant s certificate for signing (table 15) corresponding to the specified pseudonymous credit card brand by the cardholder (table 16) Cert The merchant s key-exchange certificate (table 15) corresponding to the specified pseudonymous credit card brand by the cardholder (table 16) The cardholder processes this message as described in section When this phase is completed, the cardholder starts the actual payment process. 16

17 11.3 Purchase Request (PReq) During this phase, the cardholder prepares the necessary information for the merchant, the merchant s payment gateway, the PCCP, and the PCCP s payment gateway. Compared to the PReq message in SET, the corresponding message in PSET contains more data. In the first step, the Order Information Data (OIData) is created. The OIData contains the information for the merchant. OIData is built in the same way as described in section 4.3; we only change the notation slightly, as illustrated in table 18. The Hashed Order Description (HOD) is defined as in table 5. OIData Table 18: The Order Information Data (OIData) TransID, HOD, ODSalt, BrandID TransID The ID identifying the whole transaction HOD The hash on the OD (table 5) ODSalt The salt used in HOD (table 5) BrandID An ID specifying the brand of the pseudonymous credit card The customer also computes a hash on OIData, the Hashed Order Information Data (HOIData). This works as described in table 7 in section 4.3. While only one payment information was required in SET, we now need two. The two PIData are basically built as described in table 8 in section 4.3, but it is crucial that each of the two payment gateways only gets the data that is intended for it. Table 19 defines PIData, the payment information for the merchant s payment gateway. Table 19: The Payment Information Data for the Merchant s Payment Gateway (PIData ) PIData TransID, HOD, PurchAmt, MerchantID, PCC TransID The ID identifying the whole transaction HOD The hash on the OD (table 5) PurchAmt The amount of the transaction MerchantID An ID identifying the merchant (extracted from Cert ) PCC Data identifying the cardholder s pseudonymous credit card (such as the credit card number) The customer also computes a hash on the payment information data for the merchant s payment gateway (PIData ), as this is used later. Table 20 describes HPIData. Table 20: The Hash of the PIData for the Merchant s Payment Gateway (HPIData ) HPIData Hash(PIData ) PIData The payment information data for the merchant s payment gateway (table 19) The second payment information data is intended for the PCCP s payment gateway. Table 21 defines PIData, the payment information for the PCCP s payment gateway. The customer also computes a hash on PIData, as this is used later. Table 22 describes HPIData. In SET, the dual signature was used to link order and payment information such that it is not possible for the cardholder or the merchant to cheat (section 6). In PSET, we need two dual signatures since we have two payment informations, and these dual signatures have to be created with the different private keys of the cardholder (the one corresponding to the cardholder s real certificate and the one corresponding to the cardholder s pseudonymous certificate). 17

18 Table 21: The Payment Information Data for the PCCP s Payment Gateway (PIData ) PIData TransID, PurchAmt, PCCPID, CC TransID The ID identifying the whole transaction PurchAmt The amount of the transaction PCCPID An ID identifying the PCCP (extracted from Cert ) CC Data identifying the cardholder s real credit card Table 22: The Hash of the PIData for the PCCP s Payment Gateway (HPIData ) HPIData Hash(PIData ) PIData The payment information data for the PCCP s payment gateway (table 21) To link the OIData and the PIData, the customer computes the dual signature DS. This dual signature is basically computed in the same way as described in table 10 in section 4.3 and is signed with cardholder s pseudonymous private key PrK (table 15). Table 23 describes how this first dual signature is defined. Table 23: The Dual Signature signed by the Cardholder with the Pseudonymous Private Key (DS ) DS Sign (Hash(HOIData, HPIData )) HOIData The hashed order information data (table 7) HPIData The hashed payment information data for the merchant s payment gateway (table 20) The second dual signature is needed to link the OIData and the PIData. This dual signature is basically computed in the same way as described in table 10 in section 4.3 and is signed by the cardholder using the real private key PrK (table 15). Table 24 describes how the customer computes DS. Table 24: The Dual Signature signed by the Cardholder with the Real Private Key(DS ) DS Sign (Hash(HOIData, HPIData )) HOIData The hashed order information data (table 7) HPIData The hashed payment information data for the PCCP s payment gateway (table 22) There is an additional piece of data the cardholder has to provide. The PCCP has to know the brand of the cardholder s real credit card. This is needed for the PCCP to forward the payment information to the correct payment gateway (which handles that particular brand of credit card). We name this credit card information CCI, and it is defined in table 25. Table 25: The Credit Card Information for the PCCP (CCI ) CCI E (BrandID ), E (K ) E (BrandID ) An ID specifying the brand of the credit card to use, encrypted with a one-time symmetric key K E (K ) The one-time symmetric key K, encrypted with the key-exchange public key PuK of the PCCP 18

19 The customer now builds the whole PReq message it sends to the merchant. In a first step, the payment information PI for the PCCP s payment gateway is constructed. This is done similar as in table 11 of section 4.3, with the main difference that this time the dual signature is encrypted for the payment gateway, along with the other data. Table 26 illustrates how the payment information for the PCCP s payment gateway is constructed. Table 26: The Payment Information for the PCCP s Payment Gateway (PI ) PI E (PIData, HOIData, DS, Cert ) E (K ) E (PIData, The PIData (table 21), HOIData, DS, Cert ) the HOIData (table 7), the DS (table 23); and the cardholder s real certificate Cert for signing; encrypted with a one-time symmetric key K E (K ) The one-time symmetric key K, encrypted with the key-exchange public key PuK of the PCCP s payment gateway If we compare this payment information to the one in SET, then there are two differences. The first is that the cardholder s real certificate for signing is included. The reason for this is that no other entity involved in the payment from merchant via the merchant s payment gateway to the PCCP is allowed to learn the real identity of the cardholder. The second difference is that the dual signature is part of the encrypted payload, whereas in SET it isn t. The reason for this is that neither the merchant, not the merchant s payment gateway, nor the PCCP are allowed to see the dual signature made with the cardholder s real private key. Note that when constructing the two previous messages (CCI in table 25 and PI in table 26), we assumed that the cardholder possesses the certificates Cert and Cert for key-exchange with PCCP and PCCP s payment gateway. We can for instance assume that the cardholder gets them together with the PCC when obtaining the pseudonymous credit card at the PCCP. Note that this is different than the method to obtain the certificate for key-exchange of the merchant s payment gateway. That certificate is delivered to the cardholder in the PInitRes message (table 17) by the merchant. But this makes perfectly sense, since each merchant can potentially have a different payment gateway and it would not be convenient for the cardholder to store them locally all the time. There could be alternatives to this solution. We could extend the PInitReq message (table 16) sent to the merchant by including not only the brand of the pseudonymous credit card, but also the brand of the cardholder s real credit card and the identity of the PCCP that issued the pseudonymous credit card. It would then be the merchant s duty to contact PCCP to request the two required certificates. The merchant would then send three certificates for key-exchange back in an extended PInitRes message (table 17). Note that this would slightly compromise the cardholder s anonymity, since the merchant would learn the brand of his real credit card. In a second step, the payment information PI for the merchant s payment gateway is constructed. This again is done similar as in table 11 of section 4.3, with the main difference that this time the payment information for the merchant s gateway includes the payment information for the PCCP s payment gateway. Table 27 illustrates how this done. The cardholder is now ready to generate the whole Purchase Request message. Table 28 defines how PReq is constructed. 19

Visa/MasterCard Secure Electronic Transactions (SET) Scope of SET Protocols

Visa/MasterCard Secure Electronic Transactions (SET) Scope of SET Protocols Visa/MasterCard Secure Electronic Transactions (SET) Specification of the Official method of achieving network payment via Credit Cards Announced in February 1996 Supported by Visa, MasterCard, GTE, IBM,

More information

Payment authorization Payment capture Table 1.3 SET Transaction Types

Payment authorization Payment capture Table 1.3 SET Transaction Types Table 1.3 lists the transaction types supported by SET. In what follows we look in some detail at the following transactions: Purchase request Payment authorization Payment capture Cardholder registration

More information

Secure Electronic Transaction (SET protocol) Yang Li & Yun Wang

Secure Electronic Transaction (SET protocol) Yang Li & Yun Wang Secure Electronic Transaction (SET protocol) Yang Li & Yun Wang 1 1. Introduction Electronic commerce, as exemplified by the popularity of the Internet, is going to have an enormous impact on the financial

More information

MOBILE CHIP ELECTRONIC COMMERCE: ENABLING CREDIT CARD PAYMENT FOR MOBILE DEVICES

MOBILE CHIP ELECTRONIC COMMERCE: ENABLING CREDIT CARD PAYMENT FOR MOBILE DEVICES MOBILE CHIP ELECTRONIC COMMERCE: ENABLING CREDIT CARD PAYMENT FOR MOBILE DEVICES Marko Schuba and Konrad Wrona Ericsson Research, Germany ABSTRACT This paper describes the Mobile Chip Electronic Commerce

More information

Account-Based Electronic Payment Systems

Account-Based Electronic Payment Systems Account-Based Electronic Payment Systems Speaker: Jerry Gao Ph.D. San Jose State University email: jerrygao@email.sjsu.edu URL: http://www.engr.sjsu.edu/gaojerry Sept., 2000 Topic: Account-Based Electronic

More information

Towards Pseudonymous e-commerce

Towards Pseudonymous e-commerce Electronic Commerce Research, 4: 83 111 (2004) 2004 Kluwer Academic Publishers. Manufactured in the Netherlands. Towards Pseudonymous e-commerce MARC RENNHARD Swiss Federal Institute of Technology, Computer

More information

Part I System Design Considerations

Part I System Design Considerations as of December 10, 1998 Page 1 Overview Part I System Design Considerations Introduction Part I summarizes system design considerations to be used in developing SET toolkits and applications. It provides

More information

10 Secure Electronic Transactions: Overview, Capabilities, and Current Status

10 Secure Electronic Transactions: Overview, Capabilities, and Current Status 10 Secure Electronic Transactions: Overview, Capabilities, and Current Status Gordon Agnew A&F Consulting, and University of Waterloo, Ontario, Canada 10.1 Introduction Until recently, there were two primary

More information

We describe our attack in Section 3. Finally, we conclude in Section 4 by a brief review of the related works.

We describe our attack in Section 3. Finally, we conclude in Section 4 by a brief review of the related works. Information Processing Letters 97 (2006) 104 108 www.elsevier.com/locate/ipl A flaw in the electronic commerce protocol SET S. Brlek a,2, S. Hamadou b,1, J. Mullins b,,2 a Laboratoire LaCIM, Département

More information

Electronic Commerce. 4. Payment Schemes. V Rajaraman. In this part, we will describe payments using credit cards and cheques in e-commerce.

Electronic Commerce. 4. Payment Schemes. V Rajaraman. In this part, we will describe payments using credit cards and cheques in e-commerce. Electronic Commerce 4. Payment Schemes V Rajaraman In this part, we will describe payments using credit cards and cheques in e-commerce. V Rajaraman is with the Jawaharlal Nehru Centre for Advanced Scientific

More information

Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) Public Key Infrastructure (PKI) In this video you will learn the quite a bit about Public Key Infrastructure and how it is used to authenticate clients and servers. The purpose of Public Key Infrastructure

More information

Common security requirements Basic security tools. Example. Secret-key cryptography Public-key cryptography. Online shopping with Amazon

Common security requirements Basic security tools. Example. Secret-key cryptography Public-key cryptography. Online shopping with Amazon 1 Common security requirements Basic security tools Secret-key cryptography Public-key cryptography Example Online shopping with Amazon 2 Alice credit card # is xxxx Internet What could the hacker possibly

More information

Web Payment Security. A discussion of methods providing secure communication on the Internet. Zhao Huang Shahid Kahn

Web Payment Security. A discussion of methods providing secure communication on the Internet. Zhao Huang Shahid Kahn Web Payment Security A discussion of methods providing secure communication on the Internet Group Members: Peter Heighton Zhao Huang Shahid Kahn 1. Introduction Within this report the methods taken to

More information

Network Security. Computer Networking Lecture 08. March 19, 2012. HKU SPACE Community College. HKU SPACE CC CN Lecture 08 1/23

Network Security. Computer Networking Lecture 08. March 19, 2012. HKU SPACE Community College. HKU SPACE CC CN Lecture 08 1/23 Network Security Computer Networking Lecture 08 HKU SPACE Community College March 19, 2012 HKU SPACE CC CN Lecture 08 1/23 Outline Introduction Cryptography Algorithms Secret Key Algorithm Message Digest

More information

IPsec Details 1 / 43. IPsec Details

IPsec Details 1 / 43. IPsec Details Header (AH) AH Layout Other AH Fields Mutable Parts of the IP Header What is an SPI? What s an SA? Encapsulating Security Payload (ESP) ESP Layout Padding Using ESP IPsec and Firewalls IPsec and the DNS

More information

4 Electronic Payment Systems

4 Electronic Payment Systems 4 Electronic Payment Systems 4.1 Traditional Payment Systems 4.2 Credit-Card Based Payment Standards 4.3 Electronic Cash and Micropayments 4.4 Practice of E-Payment Literature: Donal O Mahony, Michael

More information

Den Gode Webservice - Security Analysis

Den Gode Webservice - Security Analysis Den Gode Webservice - Security Analysis Cryptomathic A/S September, 2006 Executive Summary This report analyses the security mechanisms provided in Den Gode Web Service (DGWS). DGWS provides a framework

More information

Network Security Protocols

Network Security Protocols Network Security Protocols EE657 Parallel Processing Fall 2000 Peachawat Peachavanish Level of Implementation Internet Layer Security Ex. IP Security Protocol (IPSEC) Host-to-Host Basis, No Packets Discrimination

More information

Understanding Digital Signature And Public Key Infrastructure

Understanding Digital Signature And Public Key Infrastructure Understanding Digital Signature And Public Key Infrastructure Overview The use of networked personnel computers (PC s) in enterprise environments and on the Internet is rapidly approaching the point where

More information

www.studymafia.org Seminar report Digital Signature Submitted in partial fulfillment of the requirement for the award of degree Of Computer Science

www.studymafia.org Seminar report Digital Signature Submitted in partial fulfillment of the requirement for the award of degree Of Computer Science A Seminar report on Digital Signature Submitted in partial fulfillment of the requirement for the award of degree Of Computer Science SUBMITTED TO: www.studymafia.org SUBMITTED BY: www.studymafia.org Preface

More information

What is a digital certificate, why do I need one, and how do I get it?

What is a digital certificate, why do I need one, and how do I get it? PKI FAQ s What is a digital signature and how do you get one? You can t buy a digital signature. It s not like a handwritten one. A digital signature is different every time it is made, and is related

More information

Explanation of MasterCard SecureCode & Verified by Visa

Explanation of MasterCard SecureCode & Verified by Visa Explanation of MasterCard SecureCode & Verified by Visa Version: 2.2 Year: 2012 Author: Buckaroo Online Payment Services Online acceptance of MasterCard SecureCode and Verified by Visa Unfortunately, online

More information

Payment Systems for E-Commerce. Shengyu Jin 4/27/2005

Payment Systems for E-Commerce. Shengyu Jin 4/27/2005 Payment Systems for E-Commerce Shengyu Jin 4/27/2005 Reference Papers 1. Research on electronic payment model,2004 2. An analysis and comparison of different types of electronic payment systems 2001 3.

More information

WHY YOU NEED AN SSL CERTIFICATE

WHY YOU NEED AN SSL CERTIFICATE GO DADDY TECHNICAL BRIEF ecommerce SECURITY WHY YOU NEED AN SSL CERTIFICATE In the world of electronic commerce, security is paramount. Although Web sales are on the rise, widespread fears about sending

More information

Overview of CSS SSL. SSL Cryptography Overview CHAPTER

Overview of CSS SSL. SSL Cryptography Overview CHAPTER CHAPTER 1 Secure Sockets Layer (SSL) is an application-level protocol that provides encryption technology for the Internet, ensuring secure transactions such as the transmission of credit card numbers

More information

Web Security. Mahalingam Ramkumar

Web Security. Mahalingam Ramkumar Web Security Mahalingam Ramkumar Issues Phishing Spreading misinformation Cookies! Authentication Domain name DNS Security Transport layer security Dynamic HTML Java applets, ActiveX, JavaScript Exploiting

More information

Authentication Types. Password-based Authentication. Off-Line Password Guessing

Authentication Types. Password-based Authentication. Off-Line Password Guessing Authentication Types Chapter 2: Security Techniques Background Secret Key Cryptography Public Key Cryptography Hash Functions Authentication Chapter 3: Security on Network and Transport Layer Chapter 4:

More information

An Electronic Voting System Based On Blind Signature Protocol

An Electronic Voting System Based On Blind Signature Protocol CSMR, VOL. 1, NO. 1 (2011) An Electronic Voting System Based On Blind Signature Protocol Marius Ion, Ionuţ Posea University POLITEHNICA of Bucharest Faculty of Automatic Control and Computers, Computer

More information

2015-11-02. Electronic Payments Part 1

2015-11-02. Electronic Payments Part 1 Electronic Payments Part Card transactions Card-Present Smart Cards Card-Not-Present SET 3D Secure Untraceable E-Cash Micropayments Payword Electronic Lottery Tickets Peppercoin Bitcoin EITN4 - Advanced

More information

Lecture 31 SSL. SSL: Secure Socket Layer. History SSL SSL. Security April 13, 2005

Lecture 31 SSL. SSL: Secure Socket Layer. History SSL SSL. Security April 13, 2005 Lecture 31 Security April 13, 2005 Secure Sockets Layer (Netscape 1994) A Platform independent, application independent protocol to secure TCP based applications Currently the most popular internet crypto-protocol

More information

Chapter 14. Key management and Distribution. Symmetric Key Distribution Using Symmetric Encryption

Chapter 14. Key management and Distribution. Symmetric Key Distribution Using Symmetric Encryption Chapter 14. Key management and Distribution Symmetric Key Distribution Using Symmetric Encryption For symmetric encryption to work, the two parties to an exchange must share the same key, and that key

More information

Chapter 9 Key Management 9.1 Distribution of Public Keys 9.1.1 Public Announcement of Public Keys 9.1.2 Publicly Available Directory

Chapter 9 Key Management 9.1 Distribution of Public Keys 9.1.1 Public Announcement of Public Keys 9.1.2 Publicly Available Directory There are actually two distinct aspects to the use of public-key encryption in this regard: The distribution of public keys. The use of public-key encryption to distribute secret keys. 9.1 Distribution

More information

Research Article. Research of network payment system based on multi-factor authentication

Research Article. Research of network payment system based on multi-factor authentication Available online www.jocpr.com Journal of Chemical and Pharmaceutical Research, 2014, 6(7):437-441 Research Article ISSN : 0975-7384 CODEN(USA) : JCPRC5 Research of network payment system based on multi-factor

More information

Guide to Data Field Encryption

Guide to Data Field Encryption Guide to Data Field Encryption Contents Introduction 2 Common Concepts and Glossary 3 Encryption 3 Data Field Encryption 3 Cryptography 3 Keys and Key Management 5 Secure Cryptographic Device 7 Considerations

More information

2.4: Authentication Authentication types Authentication schemes: RSA, Lamport s Hash Mutual Authentication Session Keys Trusted Intermediaries

2.4: Authentication Authentication types Authentication schemes: RSA, Lamport s Hash Mutual Authentication Session Keys Trusted Intermediaries Chapter 2: Security Techniques Background Secret Key Cryptography Public Key Cryptography Hash Functions Authentication Chapter 3: Security on Network and Transport Layer Chapter 4: Security on the Application

More information

Information Security

Information Security Information Security Dr. Vedat Coşkun Malardalen September 15th, 2009 08:00 10:00 vedatcoskun@isikun.edu.tr www.isikun.edu.tr/~vedatcoskun What needs to be secured? With the rapid advances in networked

More information

Network Security. Abusayeed Saifullah. CS 5600 Computer Networks. These slides are adapted from Kurose and Ross 8-1

Network Security. Abusayeed Saifullah. CS 5600 Computer Networks. These slides are adapted from Kurose and Ross 8-1 Network Security Abusayeed Saifullah CS 5600 Computer Networks These slides are adapted from Kurose and Ross 8-1 Public Key Cryptography symmetric key crypto v requires sender, receiver know shared secret

More information

The Feasibility and Application of using a Zero-knowledge Protocol Authentication Systems

The Feasibility and Application of using a Zero-knowledge Protocol Authentication Systems The Feasibility and Application of using a Zero-knowledge Protocol Authentication Systems Becky Cutler Rebecca.cutler@tufts.edu Mentor: Professor Chris Gregg Abstract Modern day authentication systems

More information

A Secure Electronic Payment Scheme for Charity Donations

A Secure Electronic Payment Scheme for Charity Donations A Secure Electronic Payment Scheme for Charity Donations Mansour A. Al-Meaither and Chris J. Mitchell Information Security Group, Royal Holloway, University of London, Egham, Surrey, TW20 0EX, United Kingdom

More information

Key Management. CSC 490 Special Topics Computer and Network Security. Dr. Xiao Qin. Auburn University http://www.eng.auburn.edu/~xqin xqin@auburn.

Key Management. CSC 490 Special Topics Computer and Network Security. Dr. Xiao Qin. Auburn University http://www.eng.auburn.edu/~xqin xqin@auburn. CSC 490 Special Topics Computer and Network Security Key Management Dr. Xiao Qin Auburn University http://www.eng.auburn.edu/~xqin xqin@auburn.edu Slide 09-1 Overview Key exchange Session vs. interchange

More information

CS 392/681 - Computer Security

CS 392/681 - Computer Security CS 392/681 - Computer Security Module 3 Key Exchange Algorithms Nasir Memon Polytechnic University Course Issues HW 3 assigned. Any lab or course issues? Midterm in three weeks. 8/30/04 Module 3 - Key

More information

SECURITY IN ELECTRONIC COMMERCE - SOLUTION MULTIPLE-CHOICE QUESTIONS

SECURITY IN ELECTRONIC COMMERCE - SOLUTION MULTIPLE-CHOICE QUESTIONS MULTIPLE-CHOICE QUESTIONS Each question has only one correct answer, which ought to be clearly pointed out with an 'X'. Each question incorrectly answered will be evaluated as minus one third of the mark

More information

Understanding Digital Certificates & Secure Sockets Layer A Fundamental Requirement for Internet Transactions

Understanding Digital Certificates & Secure Sockets Layer A Fundamental Requirement for Internet Transactions A Fundamental Requirement for Internet Transactions May 2007 Copyright 2007 Entrust. All rights reserved. Entrust is a registered trademark of Entrust, Inc. in the United States and certain other countries.

More information

Chapter 8 Security. IC322 Fall 2014. Computer Networking: A Top Down Approach. 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012

Chapter 8 Security. IC322 Fall 2014. Computer Networking: A Top Down Approach. 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Chapter 8 Security IC322 Fall 2014 Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 All material copyright 1996-2012 J.F Kurose and K.W. Ross, All

More information

Cryptography: Authentication, Blind Signatures, and Digital Cash

Cryptography: Authentication, Blind Signatures, and Digital Cash Cryptography: Authentication, Blind Signatures, and Digital Cash Rebecca Bellovin 1 Introduction One of the most exciting ideas in cryptography in the past few decades, with the widest array of applications,

More information

Understanding Digital Certificates & Secure Sockets Layer (SSL): A Fundamental Requirement for Internet Transactions

Understanding Digital Certificates & Secure Sockets Layer (SSL): A Fundamental Requirement for Internet Transactions Understanding Digital Certificates & Secure Sockets Layer (SSL): A Fundamental Requirement for Internet Transactions February 2005 All rights reserved. Page i Entrust is a registered trademark of Entrust,

More information

Using Strong Authentication for Preventing Identity Theft

Using Strong Authentication for Preventing Identity Theft Position Paper Using Strong Authentication for Preventing Identity Theft Robert Pinheiro Consulting LLC Better identity authentication has been proposed as a potential solution not only to identity theft,

More information

Electronic Payment Systems

Electronic Payment Systems Electronic Payment Systems In any commercial transaction payment is an integral part for goods supplied. Four types of payments may be made in e-commerce they are Credit card payments Electronic cheque

More information

Strong Security in Multiple Server Environments

Strong Security in Multiple Server Environments White Paper Strong Security in Multiple Server Environments VeriSign OnSite for Server IDs Contents 1. Introduction 1 2. Security Solutions: The Digital ID System 2 2.1. What Is a Digital ID? 2 2.2 How

More information

Internet Programming. Security

Internet Programming. Security Internet Programming Security Introduction Security Issues in Internet Applications A distributed application can run inside a LAN Only a few users have access to the application Network infrastructures

More information

KEY DISTRIBUTION: PKI and SESSION-KEY EXCHANGE. Mihir Bellare UCSD 1

KEY DISTRIBUTION: PKI and SESSION-KEY EXCHANGE. Mihir Bellare UCSD 1 KEY DISTRIBUTION: PKI and SESSION-KEY EXCHANGE Mihir Bellare UCSD 1 The public key setting Alice M D sk[a] (C) Bob pk[a] C C $ E pk[a] (M) σ $ S sk[a] (M) M, σ Vpk[A] (M, σ) Bob can: send encrypted data

More information

Understanding Digital Certificates and Secure Sockets Layer (SSL)

Understanding Digital Certificates and Secure Sockets Layer (SSL) Understanding Digital Certificates and Secure Sockets Layer (SSL) Author: Peter Robinson January 2001 Version 1.1 Copyright 2001-2003 Entrust. All rights reserved. Digital Certificates What are they?

More information

Fraud Detection. Configuration Guide for the Fraud Detection Module v.4.2.0. epdq 2014, All rights reserved.

Fraud Detection. Configuration Guide for the Fraud Detection Module v.4.2.0. epdq 2014, All rights reserved. Configuration Guide for the Fraud Detection Module v.4.2.0 Table of Contents 1 What is the... Fraud Detection Module? 4 1.1 Benefits 1.2 Access 1.3 Contents... 4... 4... 4 2 Fraud detection... activation

More information

Secure Sockets Layer

Secure Sockets Layer SSL/TLS provides endpoint authentication and communications privacy over the Internet using cryptography. For web browsing, email, faxing, other data transmission. In typical use, only the server is authenticated

More information

Building Customer Confidence through SSL Certificates and SuperCerts

Building Customer Confidence through SSL Certificates and SuperCerts Building Customer Confidence through SSL Certificates and SuperCerts Contents 1. Overview 2. Why SSL? 3. Who needs an SSL certificate? 4. How to tell if a website is secure 5. Browser warnings 6. What

More information

What Are Certificates?

What Are Certificates? The Essentials Series: Code-Signing Certificates What Are Certificates? sponsored by by Don Jones W hat Are Certificates?... 1 Digital Certificates and Asymmetric Encryption... 1 Certificates as a Form

More information

Linear Programming Notes VII Sensitivity Analysis

Linear Programming Notes VII Sensitivity Analysis Linear Programming Notes VII Sensitivity Analysis 1 Introduction When you use a mathematical model to describe reality you must make approximations. The world is more complicated than the kinds of optimization

More information

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products Chapter 3 Cartesian Products and Relations The material in this chapter is the first real encounter with abstraction. Relations are very general thing they are a special type of subset. After introducing

More information

Store Use Only: Identification requires a valid driver s license and/or government issued photo ID

Store Use Only: Identification requires a valid driver s license and/or government issued photo ID NTB Credit Card APPLICATION INFORMATION ABOUT YOURSELF First Name Middle Initial Last Name Street Address (No P.O. Boxes) City State Zip Code Home Phone Social Security Number Date of Birth Employer Employer

More information

Securing your Online Data Transfer with SSL

Securing your Online Data Transfer with SSL Securing your Online Data Transfer with SSL A GUIDE TO UNDERSTANDING SSL CERTIFICATES, how they operate and their application 1. Overview 2. What is SSL? 3. How to tell if a Website is Secure 4. What does

More information

Verifying the SET Purchase Protocols

Verifying the SET Purchase Protocols Verifying the SET Purchase Protocols Giampaolo Bella Univ. of Cambridge Fabio Massacci Univ. of Trento Lawrence C. Paulson Univ. of Cambridge November 2001 Abstract The Secure Electronic Transaction (SET)

More information

Understanding Digital Certificates and Wireless Transport Layer Security (WTLS)

Understanding Digital Certificates and Wireless Transport Layer Security (WTLS) Understanding Digital Certificates and Wireless Transport Layer Security (WTLS) Author: Allan Macphee January 2001 Version 1.1 Copyright 2001-2003 Entrust. All rights reserved. Digital Certificates What

More information

Chapter 7: Network security

Chapter 7: Network security Chapter 7: Network security Foundations: what is security? cryptography authentication message integrity key distribution and certification Security in practice: application layer: secure e-mail transport

More information

Securing your Online Data Transfer with SSL A GUIDE TO UNDERSTANDING SSL CERTIFICATES, how they operate and their application INDEX 1. Overview 2. What is SSL? 3. How to tell if a Website is Secure 4.

More information

AN ANALYSIS AND COMPARISON OF E-COMMERCE TRANSACTION PROTOCOLS - PURCHASING ORDER

AN ANALYSIS AND COMPARISON OF E-COMMERCE TRANSACTION PROTOCOLS - PURCHASING ORDER AN ANALYSIS AND COMPARISON OF E-COMMERCE TRANSACTION PROTOCOLS - PURCHASING ORDER A Survey Paper for the completion of CMPE 298 by Judy Nguyen Summer 1999 SJSU Abstract One of the major part of E-Commerce

More information

Controller of Certification Authorities of Mauritius

Controller of Certification Authorities of Mauritius Contents Pg. Introduction 2 Public key Infrastructure Basics 2 What is Public Key Infrastructure (PKI)? 2 What are Digital Signatures? 3 Salient features of the Electronic Transactions Act 2000 (as amended)

More information

to hide away details from prying eyes. Pretty Good Privacy (PGP) utilizes many

to hide away details from prying eyes. Pretty Good Privacy (PGP) utilizes many In the world of secure email, there are many options from which to choose from to hide away details from prying eyes. Pretty Good Privacy (PGP) utilizes many cryptographical concepts to achieve a supposedly

More information

Safe payments on the Net. Chris Mitchell Information Security Group Royal Holloway, University of London http://www.isg.rhul.ac.

Safe payments on the Net. Chris Mitchell Information Security Group Royal Holloway, University of London http://www.isg.rhul.ac. Safe payments on the Net Chris Mitchell Information Security Group Royal Holloway, University of London http://www.isg.rhul.ac.uk/~cjm Internet e-commerce Focus of this talk is security issues for e-commerce

More information

SSL A discussion of the Secure Socket Layer

SSL A discussion of the Secure Socket Layer www.harmonysecurity.com info@harmonysecurity.com SSL A discussion of the Secure Socket Layer By Stephen Fewer Contents 1 Introduction 2 2 Encryption Techniques 3 3 Protocol Overview 3 3.1 The SSL Record

More information

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras Lecture - 41 Value of Information In this lecture, we look at the Value

More information

A SECURE ONLINE PAYMENT SYSTEM

A SECURE ONLINE PAYMENT SYSTEM University of Kentucky UKnowledge Theses and Dissertations--Computer Science Computer Science 2011 A SECURE ONLINE PAYMENT SYSTEM Shristi Pant University of Kentucky, shristi.pant@gmail.com Recommended

More information

Using EMV Cards to Protect E-commerce Transactions

Using EMV Cards to Protect E-commerce Transactions Using EMV Cards to Protect E-commerce Transactions Vorapranee Khu-Smith and Chris J. Mitchell Information Security Group, Royal Holloway, University of London, Egham, Surrey, TW20 0EX, United Kingdom {V.Khu-Smith,

More information

Merchant Best Practices & Guidelines

Merchant Best Practices & Guidelines National Bank of Abu Dhabi Merchant Best Practices & Guidelines Merchant Advice Version 1.0 January 24, 2016 Table of Content 1. Guidelines to reduce Merchant Risks... 3 1.1 Card Present Transactions...

More information

Is the Harris MasterCard Gift Card a credit card? No, the Harris MasterCard Gift Card is a prepaid MasterCard.

Is the Harris MasterCard Gift Card a credit card? No, the Harris MasterCard Gift Card is a prepaid MasterCard. Harris MasterCard Gift Card Frequently Asked Questions About Your Harris MasterCard Gift Card What is a Harris MasterCard Gift Card? The Harris MasterCard Gift Card is a prepaid MasterCard that can be

More information

Lecture 9: Application of Cryptography

Lecture 9: Application of Cryptography Lecture topics Cryptography basics Using SSL to secure communication links in J2EE programs Programmatic use of cryptography in Java Cryptography basics Encryption Transformation of data into a form that

More information

Complying with PCI Data Security

Complying with PCI Data Security Complying with PCI Data Security Solution BRIEF Retailers, financial institutions, data processors, and any other vendors that manage credit card holder data today must adhere to strict policies for ensuring

More information

A: This will depend on a number of factors. Things to consider and discuss with a member of our ANZ Merchant Services team are:

A: This will depend on a number of factors. Things to consider and discuss with a member of our ANZ Merchant Services team are: 1 ANZ egate FAQ s Contents Section 1 General information: page 1 Section 2 Technical information for ANZ egate Merchants: page 5 November 2010 Section 1 General information Q: What is ANZ egate? A: ANZ

More information

The Peruvian coin flip Cryptographic protocols

The Peruvian coin flip Cryptographic protocols Activity 17 The Peruvian coin flip Cryptographic protocols Age group Older elementary and up. Abilities assumed Requires counting, and recognition of odd and even numbers. Some understanding of the concepts

More information

Stronger(Security(and( Mobile'Payments'! Dramatically*Faster!and$ Cheaper'to'Implement"

Stronger(Security(and( Mobile'Payments'! Dramatically*Faster!and$ Cheaper'to'Implement !!!! Stronger(Security(and( Mobile'Payments'! Dramatically*Faster!and$ Cheaper'to'Implement" Here$is$a$simple,$cost$effective$way$to$achieve$transaction$security$for$ mobile$payments$that$allows$easy$and$secure$provisioning$of$cards.$

More information

Dr. Cunsheng DING HKUST, Hong Kong. Security Protocols. Security Protocols. Cunsheng Ding, HKUST COMP685C

Dr. Cunsheng DING HKUST, Hong Kong. Security Protocols. Security Protocols. Cunsheng Ding, HKUST COMP685C Cunsheng Ding, HKUST Lecture 06: Public-Key Infrastructure Main Topics of this Lecture 1. Digital certificate 2. Certificate authority (CA) 3. Public key infrastructure (PKI) Page 1 Part I: Digital Certificates

More information

Module 8. Network Security. Version 2 CSE IIT, Kharagpur

Module 8. Network Security. Version 2 CSE IIT, Kharagpur Module 8 Network Security Lesson 2 Secured Communication Specific Instructional Objectives On completion of this lesson, the student will be able to: State various services needed for secured communication

More information

Authentication. Agenda. IT Security course Lecture April 14 th 2003. Niels Christian Juul 2. April 14th, 2003

Authentication. Agenda. IT Security course Lecture April 14 th 2003. Niels Christian Juul 2. April 14th, 2003 Authentication IT Security course Lecture April 14 th 2003 Niels Christian Juul Computer Science, building 42.1 Roskilde University Universitetsvej 1 P.O. Box 260 DK-4000 Roskilde Denmark Phone: +45 4674

More information

WIRELESS LAN SECURITY FUNDAMENTALS

WIRELESS LAN SECURITY FUNDAMENTALS WIRELESS LAN SECURITY FUNDAMENTALS Jone Ostebo November 2015 #ATM15ANZ @ArubaANZ Learning Goals Authentication with 802.1X But first: We need to understand some PKI And before that, we need a cryptography

More information

Internet Usage (as of November 1, 2011)

Internet Usage (as of November 1, 2011) ebusiness Chapter 11 Online Payment Systems Internet Usage (as of November 1, 2011) United States Population: 312,521,655 Internet users: 245,000,000 (78.4% of population) Facebook users: 151,350,260 (61.8%

More information

RSA Encryption. Tom Davis tomrdavis@earthlink.net http://www.geometer.org/mathcircles October 10, 2003

RSA Encryption. Tom Davis tomrdavis@earthlink.net http://www.geometer.org/mathcircles October 10, 2003 RSA Encryption Tom Davis tomrdavis@earthlink.net http://www.geometer.org/mathcircles October 10, 2003 1 Public Key Cryptography One of the biggest problems in cryptography is the distribution of keys.

More information

Key Management and Distribution

Key Management and Distribution Key Management and Distribution Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 Jain@cse.wustl.edu Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-11/

More information

IBM i Version 7.3. Security Digital Certificate Manager IBM

IBM i Version 7.3. Security Digital Certificate Manager IBM IBM i Version 7.3 Security Digital Certificate Manager IBM IBM i Version 7.3 Security Digital Certificate Manager IBM Note Before using this information and the product it supports, read the information

More information

A simple tscheme guide to securing electronic transactions

A simple tscheme guide to securing electronic transactions A simple tscheme guide to securing electronic transactions 1 A simple tscheme guide to securing electronic transactions Electronic Transactions An electronic transaction is best thought of as a type of

More information

Modeling and verification of security protocols

Modeling and verification of security protocols Modeling and verification of security protocols Part I: Basics of cryptography and introduction to security protocols Dresden University of Technology Martin Pitt martin@piware.de Paper and slides available

More information

The Concept of Trust in Network Security

The Concept of Trust in Network Security En White Paper Date: August 2000 Version: 1.2 En is a registered trademark of En, Inc. in the United States and certain other countries. En is a registered trademark of En Limited in Canada. All other

More information

CODE SIGNING. Why Developers Need to Digitally Sign Code and Applications. +1-888-690-2424 entrust.com

CODE SIGNING. Why Developers Need to Digitally Sign Code and Applications. +1-888-690-2424 entrust.com CODE SIGNING Why Developers Need to Digitally Sign Code and Applications +1-888-690-2424 entrust.com Table of contents Why Code Sign? Page 3 What is Code Signing? Page 4 Verifying Code Authenticity Page

More information

What is network security?

What is network security? Network security Network Security Srinidhi Varadarajan Foundations: what is security? cryptography authentication message integrity key distribution and certification Security in practice: application

More information

The Mathematics 11 Competency Test Percent Increase or Decrease

The Mathematics 11 Competency Test Percent Increase or Decrease The Mathematics 11 Competency Test Percent Increase or Decrease The language of percent is frequently used to indicate the relative degree to which some quantity changes. So, we often speak of percent

More information

NATIONAL BANK s MasterCard SecureCode / Verified by VISA Service - Questions and Answers

NATIONAL BANK s MasterCard SecureCode / Verified by VISA Service - Questions and Answers Learn more about MasterCard SecureCode / Verified by VISA service of NATIONAL BANK. You can use the links below to jump to specific topics, or scroll down the page to read the full list of questions and

More information

5544 = 2 2772 = 2 2 1386 = 2 2 2 693. Now we have to find a divisor of 693. We can try 3, and 693 = 3 231,and we keep dividing by 3 to get: 1

5544 = 2 2772 = 2 2 1386 = 2 2 2 693. Now we have to find a divisor of 693. We can try 3, and 693 = 3 231,and we keep dividing by 3 to get: 1 MATH 13150: Freshman Seminar Unit 8 1. Prime numbers 1.1. Primes. A number bigger than 1 is called prime if its only divisors are 1 and itself. For example, 3 is prime because the only numbers dividing

More information

State of Arkansas Policy Statement on the Use of Electronic Signatures by State Agencies June 2008

State of Arkansas Policy Statement on the Use of Electronic Signatures by State Agencies June 2008 State of Arkansas Policy Statement on the Use of Electronic Signatures by State Agencies June 2008 Background In the last ten years Arkansas has enacted several laws to facilitate electronic transactions

More information

E-commerce. business. technology. society. Kenneth C. Laudon Carol Guercio Traver. Second Edition. Copyright 2007 Pearson Education, Inc.

E-commerce. business. technology. society. Kenneth C. Laudon Carol Guercio Traver. Second Edition. Copyright 2007 Pearson Education, Inc. Copyright 2007 Pearson Education, Inc. Slide 5-1 E-commerce business. technology. society. Second Edition Kenneth C. Laudon Carol Guercio Traver Copyright 2007 Pearson Education, Inc. Slide 5-2 Chapter

More information

CSC 774 -- Network Security

CSC 774 -- Network Security CSC 774 -- Network Security Topic 4.1: NetBill Dr. Peng Ning CSC 774 Network Security 1 Outline Why is NetBill developed? NetBill Transaction Model NetBill Transaction Protocol Basic Protocol Optimizations

More information

MasterCard SecureCode Building Consumer Confidence, Extending Your Market Reach

MasterCard SecureCode Building Consumer Confidence, Extending Your Market Reach An Introduction for Issuers MasterCard SecureCode Building Consumer Confidence, Extending Your Market Reach The time is now for gaining greater control over nonface-to-face transactions, reassuring consumers

More information