CA2543094C - Transaction verification protocol for smart cards - Google Patents
Transaction verification protocol for smart cards Download PDFInfo
- Publication number
- CA2543094C CA2543094C CA002543094A CA2543094A CA2543094C CA 2543094 C CA2543094 C CA 2543094C CA 002543094 A CA002543094 A CA 002543094A CA 2543094 A CA2543094 A CA 2543094A CA 2543094 C CA2543094 C CA 2543094C
- Authority
- CA
- Canada
- Prior art keywords
- participant
- message
- verifying
- information pertaining
- sending
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000012795 verification Methods 0.000 title claims abstract description 13
- 238000000034 method Methods 0.000 claims description 27
- 230000000977 initiatory effect Effects 0.000 claims description 4
- GNFTZDOKVXKIBK-UHFFFAOYSA-N 3-(2-methoxyethoxy)benzohydrazide Chemical compound COCCOC1=CC=CC(C(=O)NN)=C1 GNFTZDOKVXKIBK-UHFFFAOYSA-N 0.000 claims 1
- FGUUSXIOTUKUDN-IBGZPJMESA-N C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 Chemical compound C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 FGUUSXIOTUKUDN-IBGZPJMESA-N 0.000 claims 1
- YTAHJIFKAKIKAV-XNMGPUDCSA-N [(1R)-3-morpholin-4-yl-1-phenylpropyl] N-[(3S)-2-oxo-5-phenyl-1,3-dihydro-1,4-benzodiazepin-3-yl]carbamate Chemical compound O=C1[C@H](N=C(C2=C(N1)C=CC=C2)C1=CC=CC=C1)NC(O[C@H](CCN1CCOCC1)C1=CC=CC=C1)=O YTAHJIFKAKIKAV-XNMGPUDCSA-N 0.000 claims 1
- TVZRAEYQIKYCPH-UHFFFAOYSA-N 3-(trimethylsilyl)propane-1-sulfonic acid Chemical compound C[Si](C)(C)CCCS(O)(=O)=O TVZRAEYQIKYCPH-UHFFFAOYSA-N 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 230000001939 inductive effect Effects 0.000 description 2
- 101000800055 Homo sapiens Testican-1 Proteins 0.000 description 1
- 102100033390 Testican-1 Human genes 0.000 description 1
- 230000002547 anomalous effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
Landscapes
- Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
A protocol appropriate for smartcard purchase applications such as those that might be completed between a terminal or ATM and a users personal card is disclosed. The protocol provides a signature scheme which allows the card to authenticate the terminal without unnecessary signature verification which is an computationally intense operation for the smart card. The only signature verification required is that of the terminal identification (as signed by the certifying authority, or CA, which is essential to any such protocol). In the preferred embodiment, the protocol provides the card and terminal from fraudulent attacks from impostor devices, either a card or terminal.
Description
TRANSACTION VERIFICATION PROTOCOL FOR SMART CARDS
The present invention relates to methods for verifying the authenticity of partners in an electronic transaction.
It has become widely accepted to conduct transactions such that as financial transactions or exchange of documents electronically. In order to verify the transaction, it is also well-known to "sign" the transaction digitally so that the authenticity of the transaction can be verified. The signature is performed according to a protocol that utilizes the message, i.e.
the transaction, and a secret key associated with the party. Any attempt to tamper with the message or to use a key other than that of the signing party will result in an incompatibility between the message and the signature or will fail to identify the party correctly and thereby lead to rejection of the transaction.
The signature must be performed such that the parties' secret key cannot be determined.
To avoid the complexity of distributing secret keys, it is convenient to utilize a public key encryption scheme in the generation of the signature. Such capabilities are available where the transaction is conducted between parties having access to relatively large computing resources but it is equally important to facilitate such transactions at an individual level where more limited computing resources are available.
Automated teller machines (ATMs) and credit cards are widely used for personal transactions and as their use expands, so the need to verify such transactions increases.
Transaction cards are now available with limited computing capacity, so-called "Smart Cards,"
but these are not sufficient to implement existing digital signature protocols in a commercially viable manner. As noted above, in order to generate a digital signature, it is necessary to utilize a public key encryption scheme. Most public key schemes are based on the Diffie Helman Public key protocol and a particularly popular implementation is that known as DSS.
The DSS scheme utilizes the set of integers Zp where p is a large prime. For adequate security, p must be in the order of 512 bits although the resultant signature may be reduced mod q, where q divides p-1, and may be in the order of 160 bits.
The DSS protocol provides a signature composed of two components r, s. The protocol requires the selection of a secret random integer k from the set of integers (0, 1, 2, . . . q-1), i.e.
k E {0,1,2,...q-1).
The component r is then computed such that r = {[ik mod p} mod q where [3 is a generator of q.
The component s is computed as s = [k~' (h(m))+ar] mod q where m is the message to be transmitted, h(m) is a hash of the message, and a is the private key of the user.
The signature associated with the message is then s,r which may be used to verify the origin of the message from the public key of the user.
The value of (3k is computationally difficult for the DSS implementation as the exponentiation requires multiple multiplications mod p. This is beyond the capabilities of a "Smart Card" in a commercially acceptable time. Although the computation could be completed on the associated ATM, this would require the disclosure of the session key k and therefore render the private key, a, vulnerable.
An alternative encryption scheme that provides enhanced security at relatively small modules is that utilizing elliptic curves in the finite field 2m. A value of m in the order of 155 provides security comparable to a 512 bit modules for RSA and therefore offers significant benefits in implementation. Diffie Helinan Public Key encryption utilizes the properties of discrete logs so that even if a generator (3 and the exponentiation (3k are known, the value of k cannot be determined.
A similar property exists with elliptic curves where the addition of two points on a curve produces a third point on the curve. Similarly, multiplying a point by an integer k produces a point on the curve.
However, knowing the point and the origin does not reveal the value of the integer 'n' which may then be used as a session key for encryption. The value kP, where P
is an initial known point, is therefore equivalent to the exponentiation (3k.
Elliptic Curve Crytposystems (ECC) offer advantages over other public key cryptosystems when bandwidth efficiency, reduced computation, and minimized code space are application goals.
The preferred embodiment of the present invention discloses a protocol optimized for an ECC implementation for use with a "Smart Card" having limited computing capacity. The protocol has been found to provide superior performance relative to other Smart Card protocols and is achievable with an ECC implementation.
The protocol disclosed is appropriate for Smart Card purchase applications such as those that might be completed between a terminal or ATM and a users personal card.
The protocol provides a signature scheme which allows the card to authenticate the terminal without unnecessary signature verification which is a computationally intense operation for the Smart Card. The only signature verification required is that of the terminal identification (as signed by the certifying authority, or CA, which is essential to any such protocol). In the preferred embodiment, the protocol protects the card and terminal from fraudulent attacks from impostor devices, either a card or terminal.
In accordance with the invention there is provided a method of verifying a pair of participants in an electronic transaction to permit exchange of information therebetween, each of the participants includes a memory and having a respective private key t, a and public key Yt, Y
stored therein, the public keys derived from a generator a and respective ones of the private keys t, a, the method comprising the steps of (a) a first of the participants generating a unique transaction identification information P>D
upon initiation of the electronic transaction;
(b) the first participant forwarding to a second participant the transaction identification information P)D and a first certificate C1, the first certificate being signed by a certification authority according to a predetermined algorithm and including an identification information TIC1 )D unique to the first participant and the public key YI of the first participant;
(c) the second participant verifying the first certificate C1, according to the predetermined algorithm, upon receipt thereof and extracting the identification information TIU >D and the public key Y, therefrom;
(d) the second participant, upon verification of the first certificate C1, generating a first random integer R2;
(e) the second participant generating a first and second signature components r1, s1 utilizing the public key Yt of the first participant and the private key a of the second participant, S respectively according to a predetermined protocol;
(f) the second participant forwarding a message to the first participant, including the signature components r1, s1 and a second certificate C2 signed by the certification authority according to a predetermined algorithm and including an identification information CID unique to the second participant and the public key Yc of the second participant;
(g) the first participant verifying the second certificate C2 and extracting the identification information ClD and public key Y~ and verifying the authenticity of the second participant by extracting the transaction identification information P)D from the received message and comparing the received transaction identification information PID
to the transmitted value;
(h) the first participant extracting the first random integer R2 from the received message and transmitting the first random integer R2 to the second participant to acknowledge verification of the second participant; and (i) the second participant verifying the authenticity of the first participant by comparing the received first random integer R2 to the generated first random integer R2 and transmitting a second random integer R3 to the first participant to acknowledge verification of the first participant, thereby permitting exchange of information between the participants.
An embodiment of the invention will now be described by way of example only with reference to the accompanying drawings, in which:
Figure 1 is a diagrammatic representation of a scanning terminal and personal transaction card; and Figure 2 is a chart that schematically illustrates the protocol.
Referring therefore to figure 1, a scanner terminal 10 has an inductive coupling 12 to cooperate with a card 14. When a card 14 is passed through the inductive coupling 12 a transaction is recorded within a memory 16 on the card 14. Typically the transaction will debit the card with a set amount, e.g. an admission price, and the terminal 10 is credited a corresponding amount. The terminal is connected through a network to a central computer located at a financial institution that maintains records of transactions in a conventional S manner.
To avoid fraudulent transactions being recorded at either the card or terminal the protocol shown in figure 2 is utilized.
Upon the scanner sensing the card through coupling 12, a unique purchase LD.
(PID) is generated by the terminal 10. The terminal 10 has a private key, t, stored in a secure location and a corresponding public key Yt equal to a'. The terminal 10 generates a message, M1, consisting of the purchase LD. P1D and the transaction amount, TA. It also appends to the message M1 a certificate signed by the certifying authority CA that includes terminal identification information TIU ID and the public key Y~. The message M1 is received by the card 14.
1 S Card 14 has a private key a stored securely in memory 16 and a public key Y~ equal to aa. (a is the generator point for the curve). The card verifies the terminals certificate as signed by the certifying authority CA according to a normal elliptic curve scheme.
Having verified the certificate, the card generates a pair of random numbers R2 and R3 and signs the unique purchase LD. PID using the terminals public key according to an established protocol.
To effect signing, the card generates a random integer k and computes a session parameter ak. It also computes Yak and generates signature components r1 and s1.
The component r1 is provided by M2, Ytk mod L where:
M2 is the message TA//TIU ID//R21/PID, and L = 21-1 and 1 is an integer greater or equal to the number of bits in M2. (//
signifies concatenation).
The component s1 is provided by h.a+k mod q where:
q is the order of the curve and h is a hash h(M2//ak //R3).
The card now sends signature components r1, s1 the hash h and a certificate issued by the certifying authority CA containing its ID and public key to the terminal 10.
The terminal verifies the cards credentials as signed by the CA. Given the hash h and s1 it can calculate the value akt and thereby recover the message M2 from r1 using the cards public key. As the message M2 includes the PID, the terminal is able to verify the authenticity of the card 10.
The recovered message includes R2 which is then returned to the card 10 to prove that the terminal is extracting R2 in real time, i.e. during the transit of the card through the coupling 12, using its private key. This also prevents a reply attack by the terminal 10.
The receipt of R2 also serves to acknowledge provision of the service. Upon receipt, the card checks R2 to ensure the message was recovered using the terminals private key. This confirms that the card was talking to the terminal rather than a fraudulent device which would not have the private key, t, available.
If the card confirms the receipt of R2, it transmits the random R3 to the terminal 10 to complete the transaction. R3 is required for card signature verification by the bank and so R3 is retained by the terminal 10 for central processing purposes. R3 is not released by the card until it has received R2 which confirms that the terminal 10 is performing computations in real time.
The terminal 10 is required to submit to the financial institution the stored values of R2, R3, TA, PID, TIU ID, s1 and ak in addition to the credentials of both card and terminal 10. With this information the bank card is able to reproduce hash, h, i.e.
h(M2//ak//R3) by using the cards public key Y~ to prove that the transaction was authentic.
It will be noted that the last two passes are essentially trivial and do not require computation. Accordingly the computation required by the card is minimal, being restricted to one verification and one signature that involves two exponentiations, with the balance avoiding computationally intense operations.
As indicated in figure 2, and ECC implementation is the field 2lss using an anomalous curve of this protocol would result in less bandwidth (1533 bits) and reduced computation for the Smart Card (31,000 clock cycles). The computational savings over previous protocols are possible due to features of the elliptic curve signature scheme used by the Smart Card.
The particular benefits and attributes may be summarized as:
1. The purchase identifier PID is unique and is required to prevent terminal replay to the bank. If the purchase identifier is not unique, a random number Rl will also be required to provide the equivalent of the PID.
2. The random bit string R2 is required to prevent replay to the card.
The present invention relates to methods for verifying the authenticity of partners in an electronic transaction.
It has become widely accepted to conduct transactions such that as financial transactions or exchange of documents electronically. In order to verify the transaction, it is also well-known to "sign" the transaction digitally so that the authenticity of the transaction can be verified. The signature is performed according to a protocol that utilizes the message, i.e.
the transaction, and a secret key associated with the party. Any attempt to tamper with the message or to use a key other than that of the signing party will result in an incompatibility between the message and the signature or will fail to identify the party correctly and thereby lead to rejection of the transaction.
The signature must be performed such that the parties' secret key cannot be determined.
To avoid the complexity of distributing secret keys, it is convenient to utilize a public key encryption scheme in the generation of the signature. Such capabilities are available where the transaction is conducted between parties having access to relatively large computing resources but it is equally important to facilitate such transactions at an individual level where more limited computing resources are available.
Automated teller machines (ATMs) and credit cards are widely used for personal transactions and as their use expands, so the need to verify such transactions increases.
Transaction cards are now available with limited computing capacity, so-called "Smart Cards,"
but these are not sufficient to implement existing digital signature protocols in a commercially viable manner. As noted above, in order to generate a digital signature, it is necessary to utilize a public key encryption scheme. Most public key schemes are based on the Diffie Helman Public key protocol and a particularly popular implementation is that known as DSS.
The DSS scheme utilizes the set of integers Zp where p is a large prime. For adequate security, p must be in the order of 512 bits although the resultant signature may be reduced mod q, where q divides p-1, and may be in the order of 160 bits.
The DSS protocol provides a signature composed of two components r, s. The protocol requires the selection of a secret random integer k from the set of integers (0, 1, 2, . . . q-1), i.e.
k E {0,1,2,...q-1).
The component r is then computed such that r = {[ik mod p} mod q where [3 is a generator of q.
The component s is computed as s = [k~' (h(m))+ar] mod q where m is the message to be transmitted, h(m) is a hash of the message, and a is the private key of the user.
The signature associated with the message is then s,r which may be used to verify the origin of the message from the public key of the user.
The value of (3k is computationally difficult for the DSS implementation as the exponentiation requires multiple multiplications mod p. This is beyond the capabilities of a "Smart Card" in a commercially acceptable time. Although the computation could be completed on the associated ATM, this would require the disclosure of the session key k and therefore render the private key, a, vulnerable.
An alternative encryption scheme that provides enhanced security at relatively small modules is that utilizing elliptic curves in the finite field 2m. A value of m in the order of 155 provides security comparable to a 512 bit modules for RSA and therefore offers significant benefits in implementation. Diffie Helinan Public Key encryption utilizes the properties of discrete logs so that even if a generator (3 and the exponentiation (3k are known, the value of k cannot be determined.
A similar property exists with elliptic curves where the addition of two points on a curve produces a third point on the curve. Similarly, multiplying a point by an integer k produces a point on the curve.
However, knowing the point and the origin does not reveal the value of the integer 'n' which may then be used as a session key for encryption. The value kP, where P
is an initial known point, is therefore equivalent to the exponentiation (3k.
Elliptic Curve Crytposystems (ECC) offer advantages over other public key cryptosystems when bandwidth efficiency, reduced computation, and minimized code space are application goals.
The preferred embodiment of the present invention discloses a protocol optimized for an ECC implementation for use with a "Smart Card" having limited computing capacity. The protocol has been found to provide superior performance relative to other Smart Card protocols and is achievable with an ECC implementation.
The protocol disclosed is appropriate for Smart Card purchase applications such as those that might be completed between a terminal or ATM and a users personal card.
The protocol provides a signature scheme which allows the card to authenticate the terminal without unnecessary signature verification which is a computationally intense operation for the Smart Card. The only signature verification required is that of the terminal identification (as signed by the certifying authority, or CA, which is essential to any such protocol). In the preferred embodiment, the protocol protects the card and terminal from fraudulent attacks from impostor devices, either a card or terminal.
In accordance with the invention there is provided a method of verifying a pair of participants in an electronic transaction to permit exchange of information therebetween, each of the participants includes a memory and having a respective private key t, a and public key Yt, Y
stored therein, the public keys derived from a generator a and respective ones of the private keys t, a, the method comprising the steps of (a) a first of the participants generating a unique transaction identification information P>D
upon initiation of the electronic transaction;
(b) the first participant forwarding to a second participant the transaction identification information P)D and a first certificate C1, the first certificate being signed by a certification authority according to a predetermined algorithm and including an identification information TIC1 )D unique to the first participant and the public key YI of the first participant;
(c) the second participant verifying the first certificate C1, according to the predetermined algorithm, upon receipt thereof and extracting the identification information TIU >D and the public key Y, therefrom;
(d) the second participant, upon verification of the first certificate C1, generating a first random integer R2;
(e) the second participant generating a first and second signature components r1, s1 utilizing the public key Yt of the first participant and the private key a of the second participant, S respectively according to a predetermined protocol;
(f) the second participant forwarding a message to the first participant, including the signature components r1, s1 and a second certificate C2 signed by the certification authority according to a predetermined algorithm and including an identification information CID unique to the second participant and the public key Yc of the second participant;
(g) the first participant verifying the second certificate C2 and extracting the identification information ClD and public key Y~ and verifying the authenticity of the second participant by extracting the transaction identification information P)D from the received message and comparing the received transaction identification information PID
to the transmitted value;
(h) the first participant extracting the first random integer R2 from the received message and transmitting the first random integer R2 to the second participant to acknowledge verification of the second participant; and (i) the second participant verifying the authenticity of the first participant by comparing the received first random integer R2 to the generated first random integer R2 and transmitting a second random integer R3 to the first participant to acknowledge verification of the first participant, thereby permitting exchange of information between the participants.
An embodiment of the invention will now be described by way of example only with reference to the accompanying drawings, in which:
Figure 1 is a diagrammatic representation of a scanning terminal and personal transaction card; and Figure 2 is a chart that schematically illustrates the protocol.
Referring therefore to figure 1, a scanner terminal 10 has an inductive coupling 12 to cooperate with a card 14. When a card 14 is passed through the inductive coupling 12 a transaction is recorded within a memory 16 on the card 14. Typically the transaction will debit the card with a set amount, e.g. an admission price, and the terminal 10 is credited a corresponding amount. The terminal is connected through a network to a central computer located at a financial institution that maintains records of transactions in a conventional S manner.
To avoid fraudulent transactions being recorded at either the card or terminal the protocol shown in figure 2 is utilized.
Upon the scanner sensing the card through coupling 12, a unique purchase LD.
(PID) is generated by the terminal 10. The terminal 10 has a private key, t, stored in a secure location and a corresponding public key Yt equal to a'. The terminal 10 generates a message, M1, consisting of the purchase LD. P1D and the transaction amount, TA. It also appends to the message M1 a certificate signed by the certifying authority CA that includes terminal identification information TIU ID and the public key Y~. The message M1 is received by the card 14.
1 S Card 14 has a private key a stored securely in memory 16 and a public key Y~ equal to aa. (a is the generator point for the curve). The card verifies the terminals certificate as signed by the certifying authority CA according to a normal elliptic curve scheme.
Having verified the certificate, the card generates a pair of random numbers R2 and R3 and signs the unique purchase LD. PID using the terminals public key according to an established protocol.
To effect signing, the card generates a random integer k and computes a session parameter ak. It also computes Yak and generates signature components r1 and s1.
The component r1 is provided by M2, Ytk mod L where:
M2 is the message TA//TIU ID//R21/PID, and L = 21-1 and 1 is an integer greater or equal to the number of bits in M2. (//
signifies concatenation).
The component s1 is provided by h.a+k mod q where:
q is the order of the curve and h is a hash h(M2//ak //R3).
The card now sends signature components r1, s1 the hash h and a certificate issued by the certifying authority CA containing its ID and public key to the terminal 10.
The terminal verifies the cards credentials as signed by the CA. Given the hash h and s1 it can calculate the value akt and thereby recover the message M2 from r1 using the cards public key. As the message M2 includes the PID, the terminal is able to verify the authenticity of the card 10.
The recovered message includes R2 which is then returned to the card 10 to prove that the terminal is extracting R2 in real time, i.e. during the transit of the card through the coupling 12, using its private key. This also prevents a reply attack by the terminal 10.
The receipt of R2 also serves to acknowledge provision of the service. Upon receipt, the card checks R2 to ensure the message was recovered using the terminals private key. This confirms that the card was talking to the terminal rather than a fraudulent device which would not have the private key, t, available.
If the card confirms the receipt of R2, it transmits the random R3 to the terminal 10 to complete the transaction. R3 is required for card signature verification by the bank and so R3 is retained by the terminal 10 for central processing purposes. R3 is not released by the card until it has received R2 which confirms that the terminal 10 is performing computations in real time.
The terminal 10 is required to submit to the financial institution the stored values of R2, R3, TA, PID, TIU ID, s1 and ak in addition to the credentials of both card and terminal 10. With this information the bank card is able to reproduce hash, h, i.e.
h(M2//ak//R3) by using the cards public key Y~ to prove that the transaction was authentic.
It will be noted that the last two passes are essentially trivial and do not require computation. Accordingly the computation required by the card is minimal, being restricted to one verification and one signature that involves two exponentiations, with the balance avoiding computationally intense operations.
As indicated in figure 2, and ECC implementation is the field 2lss using an anomalous curve of this protocol would result in less bandwidth (1533 bits) and reduced computation for the Smart Card (31,000 clock cycles). The computational savings over previous protocols are possible due to features of the elliptic curve signature scheme used by the Smart Card.
The particular benefits and attributes may be summarized as:
1. The purchase identifier PID is unique and is required to prevent terminal replay to the bank. If the purchase identifier is not unique, a random number Rl will also be required to provide the equivalent of the PID.
2. The random bit string R2 is required to prevent replay to the card.
3. A has function (h) such as the SHA.1 is required to prevent modification of the message (m) and the terminal's identification (TIU ID).
4. There appears to be no advantage to having the transaction amount signed by the terminal, resulting in one less signature verification for the card. The reason for this is that the message signed by the card contains a random number R2 which can only be recovered by the terminal.
5. Using this scheme, the message m may only be recovered by the terminal (note the terminal's public key is used in step III therefore requiring the terminal's private key to verify and recover contents). By demonstrating to the card that the 1 S random string (R2) was obtained from the message, the terminal can be authenticated to the card.
Claims (32)
1. A method of performing a transaction in a communication system between a first and a second participant wherein said second participant permits a service to be provided to said first participant in exchange for a payment, said method comprising the steps of:
a) upon initiation of said transaction by said first participant, said second participant sending a first message to said first participant, said first message including information pertaining to said second participant;
b) said first participant verifying said information pertaining to said second participant to obtain assurance that said service will be provided upon assuring said payment;
c) said first participant sending a second message to said second participant, said second message including information pertaining to said first participant;
d) said second participant verifying said information pertaining to said first participant to obtain assurance that payment will be secured upon provision of said service;
and e) upon verification of said information pertaining to said first participant, said second participant obtaining a digital signature for said first participant on said transaction using said second message, whereby said second participant may obtain said payment from a third participant using said digital signature.
a) upon initiation of said transaction by said first participant, said second participant sending a first message to said first participant, said first message including information pertaining to said second participant;
b) said first participant verifying said information pertaining to said second participant to obtain assurance that said service will be provided upon assuring said payment;
c) said first participant sending a second message to said second participant, said second message including information pertaining to said first participant;
d) said second participant verifying said information pertaining to said first participant to obtain assurance that payment will be secured upon provision of said service;
and e) upon verification of said information pertaining to said first participant, said second participant obtaining a digital signature for said first participant on said transaction using said second message, whereby said second participant may obtain said payment from a third participant using said digital signature.
2. A method according to claim 1 wherein said first participant is a holder of a card which performs cryptographic operations.
3. A method according to claim 2 wherein said second participant is a terminal.
4. A method according to claim 3 wherein said third participant is a financial institution.
5. A method according to claim 1 wherein said information pertaining to said second participant included in said first message includes details and credentials of said second participant; and said first participant verifies said details and said credentials in step b).
6. A method according to claim 1 wherein said information pertaining to said first participant included in said second message includes details and credentials of said first participant; and said second participant verifies said details and credentials in step d).
7. A method according to claim 1 wherein said second message includes a challenge and step e) further comprises:
i) said second participant generating a response to said challenge;
ii) said second participant sending a third message including said response to said first participant;
iii) said first participant verifying said response; and iv) said first participant sending a fourth message to said second participant such that said digital signature is provided by said second message and said fourth message.
i) said second participant generating a response to said challenge;
ii) said second participant sending a third message including said response to said first participant;
iii) said first participant verifying said response; and iv) said first participant sending a fourth message to said second participant such that said digital signature is provided by said second message and said fourth message.
8. A method according to claim 7 further comprising:
i) said second participant verifying information in said fourth message;
ii) said second participant completing said transaction by providing said service; and iii) said second participant sending said third participant a subset of said first, second, third and fourth messages to obtain said payment.
i) said second participant verifying information in said fourth message;
ii) said second participant completing said transaction by providing said service; and iii) said second participant sending said third participant a subset of said first, second, third and fourth messages to obtain said payment.
9. A method according to claim 8 further comprising:
i) said third participant verifying said subset;
ii) said third participant providing said payment to said second participant.
i) said third participant verifying said subset;
ii) said third participant providing said payment to said second participant.
10. A method according to claim 5 wherein said credentials include a public key certificate.
11. A method according to claim 7 wherein said challenge is a nonce.
12. A method of performing a transaction in a communication system between a first and a second participant wherein said second participant permits a service to be provided to said first participant in exchange for a payment, said method comprising the steps of:
a) upon initiation of said transaction by said first participant, said second participant sending a first message to said first participant, said first message including information pertaining to said second participant;
b) said first participant verifying said information pertaining to said second participant;
c) said first participant generating a first value and a second value;
d) said first participant preparing a second message comprising said first value;
e) said first participant preparing a digital signature using said second message;
f) said first participant sending said digital signature and information pertaining to said first participant to said second participant;
g) said second participant verifying said information pertaining to said first participant;
h) said second participant obtaining said second message using said digital signature and obtaining said first value using said second message;
i) said second participant sending said first value to said first participant to acknowledge provision of said service; and j) said first participant verifying said first value and sending said second value to said second participant to enable said second participant to obtain said payment from a third participant using said second value.
a) upon initiation of said transaction by said first participant, said second participant sending a first message to said first participant, said first message including information pertaining to said second participant;
b) said first participant verifying said information pertaining to said second participant;
c) said first participant generating a first value and a second value;
d) said first participant preparing a second message comprising said first value;
e) said first participant preparing a digital signature using said second message;
f) said first participant sending said digital signature and information pertaining to said first participant to said second participant;
g) said second participant verifying said information pertaining to said first participant;
h) said second participant obtaining said second message using said digital signature and obtaining said first value using said second message;
i) said second participant sending said first value to said first participant to acknowledge provision of said service; and j) said first participant verifying said first value and sending said second value to said second participant to enable said second participant to obtain said payment from a third participant using said second value.
13. A method according to claim 12 wherein said first participant is a holder of a card which performs cryptographic operations.
14. A method according to claim 13 wherein said second participant is a terminal.
15. A method according to claim 14 wherein said third participant is a financial institution.
16. A method according to claim 12 wherein said information pertaining to said second participant included in said first message includes details and credentials of said second participant; and said first participant verifies said details and said credentials in step b).
17. A method according to claim 12 wherein said information pertaining to said first participant included in said second message includes details and credentials of said first participant; and said second participant verifies said details and credentials in step g).
18. A method according to claim 12 wherein said second message includes a challenge and step j) further comprises:
i) said second participant generating a response to said challenge;
ii) said second participant sending a third message including said response to said first participant;
iii) said first participant verifying said response; and iv) said first participant sending a fourth message to said second participant such that said digital signature is provided by said second message and said fourth message.
i) said second participant generating a response to said challenge;
ii) said second participant sending a third message including said response to said first participant;
iii) said first participant verifying said response; and iv) said first participant sending a fourth message to said second participant such that said digital signature is provided by said second message and said fourth message.
19. A method according to claim 18 further comprising:
i) said second participant verifying information in said fourth message;
ii) said second participant completing said transaction by providing said service; and iii) said second participant sending said third participant a subset of said first, second, third and fourth messages to obtain said payment.
i) said second participant verifying information in said fourth message;
ii) said second participant completing said transaction by providing said service; and iii) said second participant sending said third participant a subset of said first, second, third and fourth messages to obtain said payment.
20. A method according to claim 19 further comprising:
i) said third participant verifying said subset;
ii) said third participant providing said payment to said second participant.
i) said third participant verifying said subset;
ii) said third participant providing said payment to said second participant.
21. A method according to claim 16 wherein said credentials include a public key certificate.
22. A method according to claim 18 wherein said challenge is a nonce.
23. A system for performing a transaction between a first and second participant wherein said second participant permits a service to be provided to said first participant in exchange for a payment, said system comprising at least said second correspondent having a cryptographic processor that is configured for:
a) upon initiation of said transaction by said first participant, sending a first message to said first participant, said first message including information pertaining to said second participant;
b) receiving from said first participant, a digital signature and information pertaining to said first participant, said digital signature being prepared using a second message, said second message being prepared to comprise a first value, said first value being generated by said first participant along with a second value;
c) verifying said information pertaining to said first participant;
d) obtaining said second message using said digital signature and obtaining said first value using said second message;
e) sending said first value to said first participant to acknowledge provision of said service;
and f) receiving from said first participant, said second value upon said first participant verifying said first value, said second to be used to obtain payment from a third participant.
a) upon initiation of said transaction by said first participant, sending a first message to said first participant, said first message including information pertaining to said second participant;
b) receiving from said first participant, a digital signature and information pertaining to said first participant, said digital signature being prepared using a second message, said second message being prepared to comprise a first value, said first value being generated by said first participant along with a second value;
c) verifying said information pertaining to said first participant;
d) obtaining said second message using said digital signature and obtaining said first value using said second message;
e) sending said first value to said first participant to acknowledge provision of said service;
and f) receiving from said first participant, said second value upon said first participant verifying said first value, said second to be used to obtain payment from a third participant.
24. The system according to claim 23 wherein said second participant is a terminal and said first participant is a card which performs cryptographic operations.
25. The system according to claim 24 wherein said third participant is a financial institution.
26. The system according to claim 23 wherein said information pertaining to said second participant included in said first message includes details and credentials of said second participant.
27. The system according to claim 23 wherein said information pertaining to said first participant included in said second message includes details and credentials of said first participant; and said second participant verifies said details and credentials in step c).
28. The system according to claim 23 wherein said second message includes a challenge and step f) further comprises:
i) said second participant generating a response to said challenge;
ii) said second participant sending a third message including said response to said first participant; and iii) said second participant receiving from said first participant upon said first participant verifying said response, a fourth message such that said digital signature is provided by said second message and said fourth message.
i) said second participant generating a response to said challenge;
ii) said second participant sending a third message including said response to said first participant; and iii) said second participant receiving from said first participant upon said first participant verifying said response, a fourth message such that said digital signature is provided by said second message and said fourth message.
29. The system according to claim 28 further comprising:
i) said second participant verifying information in said fourth message;
ii) said second participant completing said transaction by providing said service; and iii) said second participant sending said third participant a subset of said first, second, third and fourth messages to obtain said payment.
i) said second participant verifying information in said fourth message;
ii) said second participant completing said transaction by providing said service; and iii) said second participant sending said third participant a subset of said first, second, third and fourth messages to obtain said payment.
30. The system according to claim 29 further comprising:
i) said second participant obtaining said payment from said third participant upon said third participant verifying said subset.
i) said second participant obtaining said payment from said third participant upon said third participant verifying said subset.
31. The system according to claim 26 wherein said credentials include a public key certificate.
32. The system according to claim 28 wherein said challenge is a nonce.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9601924.5 | 1996-01-31 | ||
| GBGB9601924.5A GB9601924D0 (en) | 1996-01-31 | 1996-01-31 | Transaction verification protocol for smart cards |
| CA002196356A CA2196356C (en) | 1996-01-31 | 1997-01-30 | Transaction verification protocol for smart cards |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002196356A Division CA2196356C (en) | 1996-01-31 | 1997-01-30 | Transaction verification protocol for smart cards |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2543094A1 CA2543094A1 (en) | 1997-07-31 |
| CA2543094C true CA2543094C (en) | 2007-10-16 |
Family
ID=36577310
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002543094A Expired - Lifetime CA2543094C (en) | 1996-01-31 | 1997-01-30 | Transaction verification protocol for smart cards |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2543094C (en) |
-
1997
- 1997-01-30 CA CA002543094A patent/CA2543094C/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2543094A1 (en) | 1997-07-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2196356C (en) | Transaction verification protocol for smart cards | |
| US7472276B2 (en) | Data card verification system | |
| US6446052B1 (en) | Digital coin tracing using trustee tokens | |
| Horn et al. | Authentication and payment in future mobile systems | |
| US6119227A (en) | Methods and apparatus for authenticating an originator of a message | |
| US4969189A (en) | Authentication system and apparatus therefor | |
| EP0252499B1 (en) | Method, apparatus and article for identification and signature | |
| WO1998034202A9 (en) | Data card verification system | |
| WO1995023465A1 (en) | Efficient electronic money | |
| US7228418B1 (en) | Authentication and signature method for messages using reduced size of binary units of information content and corresponding systems | |
| Brickell et al. | Interactive identification and digital signatures | |
| Simmons et al. | Zero-knowledge proofs of identity and veracity of transaction receipts | |
| JP2805493B2 (en) | Authentication method and device used therefor | |
| CA2543094C (en) | Transaction verification protocol for smart cards | |
| Rihaczek | Teletrust | |
| Farsi | Digital Cash | |
| US20070143595A1 (en) | Method of producing a digital certificate, and an associated digital certificate | |
| CN100505620C (en) | A Method of Reducing the Storage Space of RSA Key Variables | |
| VERACITY | Gustavus J. Simmons and George B. Purdyb | |
| Dawirs et al. | The Banksys Signature Transport (BST) Protocol | |
| KR19990080819A (en) | Offline electronic payment system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20170130 |