Imported from previous forum
[ original email was from Bob Lamoureux - blamoureux@bridge.com ]
Discussion of non-repudiation issues.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I first want to elaborate on the difference between authentication and non-repudiation.
Assuming the protocols are secure, the probability of someone guessing or brute forcing a key is minimal, and nobody can gain access to people’s private keys, authentication means I’m certain of the identity of the person at the other end of the connection.
Non-repudiation takes that a step further - that I can prove conclusively to a third party that the other side did the action, assuming my three assumptions above hold.
Generally, signature algorithms based on a shared secret, like the one used in PGP-DES-MD5, provide authentication but not non-repudiation. It usually takes a public key cryptosystem to provide non-repudiation.
Session level protocols can offer non-repudiation. You can individually sign each packet of bytes with a public key algorithm. And you can stand up in court and prove that the other party’s FIX engine sent these packets in this order, hence they made this trade.
But SSLv2 apparently does not use a public key method in verifying the identity of each packet, so it provides authentication but not non-repudiation. An unscrupulous firm cannot deny that they didn’t open an SSL session with you (as that uses a public-key certificate), but they can wrongly accuse you of falsifying your log of what happened on that session, and it becomes your word against theirs.
The fact that you can prove conclusively that they connected to you should be enough to deter most people from frivolously trying to deny their actions. Plus, producing a falsified SSL stream of FIX data which matches what you claim happened is non-trivial. But in a high dollar-value situation, I can see a need for non-repudiation of each transaction.
Still, I like the idea of putting encryption and authentication outside of the FIX engine. It’s much harder to mess up there; you know every byte coming in the encrypted socket is authenticated, and you don’t have to code to handle cases such as what happens when one message is properly signed and the next isn’t. And SSL allows for external proxies which is great for export control.
So I’m thinking the following would work well:
- Optionally use SSLv2 to wrap around the entire FIX protocol.
- Allow for an optional digital signature, using a public-key method, of the FIX data. I am assuming GSS-API or CDSA could be used for this.
An error allowing an order without a proper signature isn’t too terribly disastrous if SSL is used in conjunction with signatures. It means that a malicious hacker can’t be on the other end of the connection, and your only risk is the other party falsely denying their actions in court.
This situation is also ideal for export. SSL can be added as an external proxy, and the FIX engine contains only authentication code. Strong cryptography used solely for authentication is exportable, so long as it can’t be used to do encryption as well.
[ original email was from Dwight Arthur - dwightarthur@mindspring.com ]
> Session level protocols can offer non-
> repudiation. <…> But SSLv2 apparently does
> not use a public key method in verifying the
> identity of each packet, so it provides
> authentication but not non-repudiation.
I agree that one might invent a future session-level protocol that might approximate the requirements for non-repudiation. Today’s SSL is not there. For one issue, non-repudation unlike encryption is a legal issue. You have not really achieved non-repudiation unless you have something that will be enforced by a court. The chance of getting a judge and jury to review session logs and accept the assertion that there are no holes in the protection of the session, are less than the chance of getting the judge and jury to accept the validity of a single cryptographically signed message.
All of the centuries of law governing contract formation affect the effort to achieve nonrepudiation. For example, an entirely legal signature is not binding if the signer shows that she was under coercion. The same defences can be used to overcome nonrepudiation no matter how strong the technology.
Therefore, it would probably be appropriate for you to define your objective. An iron-clad unbreakable committment cannot be achieved by technology alone. Evidence that the message was probably sent by the sender and probably shows a committment of the sender is doable. Depending on how strong the assurance needs to be, there may be a need for third-party timestamping or notarization of messages, etc. IETF-PKIX draft standards show proposals for protocols to meet most of these needs. There is a subset that can be achieved using current or emerging commercial off-the-shelf software, but attempting to implement the full suite is a tall order.
Hello,
I read the power point presentation written by MR Towsend and there is one point understand.
“Accidental” disclosure of private keys makes non-repudiation close to impossible to achieve.
How is it possible?
From what I know, non-repudiation in PGP and in SSL is provided by digital signature. The message goes through a hash function that produces the digest and the digest is encrypted with the Private key of the sender.
The recipient decrypt the digest with the sender’s public Key, and then compares it with the one himself has computed with the hash function. and that provides non repudiation.
Is this sensitive for private key disclosure?
Why do we have to sign FIX messages with a shared secret instead of private key when we use PGP-DES-MD5?
thank you
Sarah
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Hello,
> I read the power point presentation written by MR Towsend and there is one point understand.
>
> “Accidental” disclosure of private keys makes non-repudiation close to impossible to achieve.
>
> How is it possible?
>
> From what I know, non-repudiation in PGP and in SSL is provided by digital signature. The message goes through a hash function that produces the digest and the digest is encrypted with the Private key of the sender.
> The recipient decrypt the digest with the sender’s public Key, and then compares it with the one himself has computed with the hash function. and that provides non repudiation.
>
> Is this sensitive for private key disclosure?
Non-repudiation means that someone cannot falsely deny having made a transaction. Over time, my opinion has changed, and I really do not believe that non-repudiation is possible with today’s technologies.
Assume that I use my 2048 bit PGP key to sign a transaction to buy a large quantity of a stock, send the order to you, you check my PGP signature, see that it is valid, and then execute the trade. That stock later becomes immediately worthless due to a surprise bankruptcy. Having bought it on margin, I’m in considerable financial trouble, and I need to do anything possible to (fraudulently) contest the transaction.
Is your firm safe? Yes, you think, because you have my digital signature on the transaction. That proves I made the transaction, right?
NO! Here lies the fundamental misconception of public key cryptography. That digital signature DOES NOT prove that I signed the document. I certainly cannot memorize my private key, nor can I perform the RSA operation in my head. An RSA signature only proves that a microprocessor with access to my private key signed the document. This is a subtle, but crucial, difference.
There are several ways that a document could be signed with my private key, without my knowledge or consent:
-
Someone could have factored my public key to obtain my private key. With a 2048 bit key, that’s considered computationally infeasible. (It makes sense to require big keys of your counterparties, since doing so generally eliminates any serious claim they can make that their keys were factored.)
-
Someone could have stolen my private key.
-
Someone could be exploiting a weakness or trojan horse in my encryption software, and could be tricking my computer into signing an order that I’ve never seen.
So I can take my private key and anonymously post it all over the Internet. Then I can stand up in front of a judge and claim that my system was compromised, an attacker stole my private key, and entered the losing trade. While you can certainly can prove that some microprocessor in posession of my secret key signed the losing order, you cannot prove to an impartial judge that I directed the microprocessor to sign the order.
Now this doesn’t mean that digital signatures have no value. Rather than speaking of non-repudiation, I find it more useful to discuss ease of fraudulent repudiation. For example, in a situation where there are no digital signatures, I could fraudulently adjust my logs so that a buy order on a losing trade would appear as a sell order. At this point, it would be my word against my broker’s word. I can blame my broker, and I don’t have to admit to any fault.
With, say, RSA signatures on each message, in order to repudiate a transaction fraudulently, I’d have to admit that my private key was hacked. This would inevitably mean that I’d lose quite a lot of face.
So while digital signatures can’t guarantee non-repudiation, they can help shift the scales substantially to make fraudulent repudiation of transactions much more unattractive.
> Why do we have to sign FIX messages with a shared secret instead of private key when we use PGP-DES-MD5?
This was implemented because doing a public key computation is generally a slow process. Signing every order with PGP would likely result in a substantial slowdown of many firms’ FIX engines, while an MD5 hash of an order and a shared secret can generally be computed fairly quickly.
Even SSLv3/TLS generally reserve actual public key computations to session negotiation; it’s my understanding that SSLv3/TLS uses a similar approach of hash functions with shared secrets exchanged through RSA.