Have you ever heard the kind of sweet and innocent voice saying, “I didn’t eat my brother’s ice cream”, while the kid’s mouth and t-shirt are covered with chocolate and cream?
Looking at this example from the mother’s perspective, just looking at the kid’s mouth would provide enough evidence. The kid will be unable to repudiate the fact of eating ice cream.When a person repudiates, it is simply rejecting something as untrue. Non-Repudiation is a term that connects a person to a fact so that they cannot deny that an action was taken. If we take this concept to the technological domain, e.g into the context of a business transaction, it means that a sender of a message cannot claim not having sent the message and cannot claim having sent a message with a different content.
Non-Repudiation of Origin (NRO) makes a link between the message and the sender of the message. It can provide legal evidence that a person in fact sent the message.
Non-Repudiation of Emission (NRE) makes a link between the sender of the message and the content of the message. It can provide legal evidence that a person sent that specific message.
From a technical point of view, RFC 4270 (Attacks on Cryptographic Hashes in Internet Protocols) points out that Non-repudiation is “a security service that provides protection against false denial of involvement in a communication”.
Today, money flows around millions of network links across the world in a wide range of e-commerce and financial operations. People want and need to be safe when executing those operations and the financial institutions should provide them that safety. Mechanisms should be in place to guarantee the users that they are making a secure transaction. In the end, Non Repudiation is really about enforcing all the mechanisms for protecting the users, as well as the banks, which can be a real challenge, technologically speaking. For non-repudiation, it is essential to have transaction evidence of participation in case of a legal dispute.
Identity of people is a matter of perspective. Authenticating people is very different from authenticating software or hardware devices. Big challenges arrive when you have to authenticate a person that uses software that, of course, resides in technological devices.
Technologically speaking, what can make you different from other people?
The most used authentication mechanism is the one that makes use of passwords. But unfortunately this mechanism is one of the most questioned and attacked. Passwords will be as safe as the way they are being stored, its character selection and length, and how secret it really is. It would be useless to have a strong 15 alphanumerical character password if the person had written it on a paper and put it on the desk.
Adding a second factor authentication (e.g., a token or fingerprint) significantly raises the validity of the user identity. Two-factor authentication generates more certainty about the identity of a person.
For NRO and NRE to be in place, any intended and critical transaction should have its guarantees for authenticity (n-Multifactor) and integrity during the operation.
Integrity means that a document or data of a transaction is reliable and stays unaltered during the life of the transaction, including the safe storing for evidence.
In the next illustration, you can see the steps needed for successfull two-factor authentication:
Infographic: Two-Factor Authentication
In the next illustration, you can see the steps needed for successful two-factor authentication and digital signing:
Infographic: Two-Factor Authentication and Digital Signing
The private key, which is used for encrypting and signing, is safe in a specific hardware security module (HSM), which is physically out of the premises of the user device.
For NRO and NRE, common threats include: Internal Attacks, Man-In-The-Browser, Man-In-The-Middle, Mining, Pharming, Phishing, Social Engineering, Trojans and Key loggers. All threats are generally looking for the same information: the “Key” for accessing information. User applications can be vulnerable when storing or manipulating user information.
As an example, Google Chrome asks its users to remember their password for them. The thing is that it does remember the password, storing it and showing it in clear text, so without too much searching, it would be enough to take look at Google Chrome’s settings. So, if you permit this browser to remember your passwords, probably you are not the only one that knows your password. Any malware can also find the way to access that information, as can be a person that briefly sits on your chair while you were looking for a soda or coffee.
Infographic: Threats in Google Chrome (example)
Another example is a Man-In-The-Middle-Attack scenario, involving the way that web servlets manage sessions with their JsessionID, generated from the browser for managing user sessions:
Infographic: Man-in-the-middle attack (example)
These examples can show some of the reasons, why multi-factor authentication should be used to avoid accommodating all user safety in client side software, and not just a single factor mechanism without reliable traces.
Financial institutions should be worried about authentication and integrity threats to its clients’ transactions. Imagine that a perpetrator could change automatic scheduling of clients transfers, or that the transfer to its intended receiver succeeds but for a different amount. What would happen if the completed transfer had been done for 20 cents more of the original amount, without the users’ knowledge? That amount is maybe not perceptible by the client. Imagine a company with a payroll of 20.000 employees (all having accounts in the same bank) has a perpetrator that has total control over a company’s proxy server and this company, 5 monthly transactions per employees would be enough for the perpetrator to earn 20.000$.
Infographic: Man-in-the-middle attack / collision attack (example)
At the time that the company or any employee gets aware of the missing cents, it could be too late, and the bank would have 20.000 users (and the company) repudiating those transactions. This is why banks should implement mechanism to have strong NRO and NRE mechanism, including multifactor authentication, strong ciphering algorithms and the secure storage of private’s keys and evidence of its transactions.
Ensuring NRO and NRE for banking transactions, means that financial institutions has to: