2

This is the first class I'm having on security and one of the concepts discussed is the SET protocol. I've read about it in many different sources and although I came into many unknown terms, after looking into them one by one I think I now have a basic understanding of the protocol.

One of the things I don't get is related to the dual signature. I realized that the dual signature came about in order to prevent merchants from altering order information and charging a customer for different items.

I think I've worked out why the dual signature prevents this from happening. However, I can't see how the dual signature prevents the customer from altering the information. I'm sure I'm missing something.

Here is my point of view.

The customer sends the dual signature to the merchant. The dual signature consists of the order information and the purchase information. There is some decryption and hashing going on but the point is the merchant can only see the order information and the 'bank' is only able to see the purchase information.

However, in every source I've found it is stated that the order information doesn't contain anything about the items or the cost of the order. So, what prevents the customer from including a different price in the purchase information?

The only thing that is common is the transaction ID. From what I've read , this ID is included in both PI and OI. I think that this ID is what tackles the problem. But again, this ID is just a number. It could be the same ID in the OI and PI but the information could still be different in each one.

I think there is more to the transaction ID than I'm aware of. Something that guarantees that the transaction ID refers to a specific order, items, price etc. Who creates this ID?

I hope my 'gap' is clear the way I described it.

John Katsantas
  • 121
  • 2
  • I don't know SET, but I think I looked it up enough to explain the signature thing. The customer computes a cryptographic hash of the order and a cryptographic hash of their payment info. They then sign the two digests. They send both digests to both parties. The merchant also gets the order, and the bank gets the payment info. The bank reports whether the customer has the money to the merchant's bank. The merchant's bank tells the merchant, who ships the goods and bills for them. The transaction ID is just an easy way to reference the set. Fraud that bypasses this is handled traditionally. – Ed Grimm Feb 06 '19 at 06:11
  • Thanks for looking it up @EdGrimm . Let's say I send the dual signature. The order information sent to the merchant states that I've ordered a video game(costing 70 euros, this is not included) for example. It includes the transaction ID eg ABCD. The merchant sees this information as correct and sends the dual signature to the bank. The purchase information include the same transaction ID ABCD but the price included is a different one , let's say 50 euros. So the merchant agreed to the correct order, but I'm sending a different price to the bank. How does the bank know I've altered the price ? – John Katsantas Feb 06 '19 at 15:28

2 Answers2

1

The dual signature is encrypted with the customer's private key, so the banks can use the public key to decrypt it. The contents of the dual signature is a hash of the digest of the purchase order and the payment info, and anyone with both digests can reproduce that value.

The merchant gets the purchase order and the digest of the payment information, so the merchant can produce the PO digest. Thus they can take that and the PI digest, hash them together, and verify whether or not it matches the decrypted dual signature.

Your bank gets the payment info and the digest of the purchase order, so your bank can produce the PI digest, and hash that with the PO digest. They can then verify that matches the decrypted dual signature. In your scenario, they're the ones that find out you've lied to them because the hash they get of the PO digest and the digest they make from the PI doesn't match your dual signature.

If the two sides don't get the same signatures, they can tell there's a difference when they talk by comparing them. If there's a difference in the documents you gave each party and the digest you gave the other party, then one of the sides won't get a match between their hash of the two digests and what was in your dual signature.

They could also just compare the digest they were given with the digest of what the other party was given, because they're allowed to talk with each other. They're just not allowed to give the unhashed documents to the other.

The transaction ID is only necessary for them to compare notes on what they're talking about.

Ed Grimm
  • 258
  • 1
  • 7
1

Any mismatch gets rejected

You don't have the ability to send your altered transaction details to the bank, only the merchant does that. The only thing that you influence is the signed message digest. Furthermore, the confidentiality is enforced by the fact that the message digest is a one-way operation - a 50 euro transaction has a different digest (and thus signature) than a 70 euro transaction, but given only that digest, you can't find out what the amount was. Both PI and OI are included in the signature in this way; and while the merchant and the bank don't have access to both PI and OI, they do have access to message digests of both PI and OI; they can't see the exact details of the confidential half, but they can verify whether the digest you signed is the same as the digest they received from the bank.

All the information in the payment is included in the message digest. If you alter anything in that the information, then you get a different message digest. If you sign the altered transaction, the merchant and the bank can see that the signature isn't valid for the transaction that the merchant is trying to send, and the transaction gets rejected.

This link has a nice illustration on how the merchant can verify whether the request is valid.

Peteris
  • 8,419
  • 1
  • 28
  • 35