Non-Repudiation of Origin and Non-Repudiation of Emission for Banks

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.

NRO and NRE, what it means

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.

Something You Know, Have, or Are, and then you can sign

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?

1. The knowledge of a unique secret (E.g. password, PIN)
2. Having a unique device that no one else has (E.g. token, card)
3. Being yourself (E.g. fingerprints, DNA)

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

1. You should see a screen for accessing the application or system (U2A), asking for your identification.
2. Entering the password or passphrase (something that only you know) to get to the system (technically to access the private key to use the SSL Certificate, or any other secure authentication mechanism).
3. Selecting usual operations that needs to have strong authentication (e.g. transfers, loans).
4. Asking to the user to enter a second factor authentication (hardware or software token, cards, matrix cards, SMS).
5. Authentication and logging completed and the transaction is done.

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

1. You should see a screen for accessing the application or system, asking for your username and password.
2. Entering the password or passphrase (something that only you know) to get to the system (technically to access the private key to use the SSL Certificate).
3. Selecting usual operations that needs to have strong authentication (e.g. transfers, loans).
4. You will see the exact information for the transaction that you need to sign.
5. Asking to the user for enter a second factor authentication (hardware or software token, cards, matrix cards, SMS).
6. Authentication is completed, so is the access to the private key for signing.
7. The document (that you are viewing gets signed with your private key)

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.

Some Threats

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.

Banking Scenarios

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:

1. Use multi-factor authentication mechanism (at least two factors).
2. Protect evidence for any important transaction.
3. Provide secure storage for the private keys, through specialized hardware.
4. Ensure that they can securely show to their clients what they would be signing using a trusted GUI (Graphical User Interface), without overloading client screens.
5. Avoid storage of keys in any user device.
6. Use of strong algorithm for hashing and encrypting.
7. Increase user awareness of internal bank security policies (e.g. using robust passwords)
8. Rely some aspects of security controls to Trusted Third Parties (TTP), that can be of an important role in case of NRO or NRE litigation.

References and Further Reading

• Selected articles on Authentication (2014-16),by Heather Walker, Luis Balbas, Guillaume Forget,and Dawn M. Turner
  
• Selected articles on Electronic Signing and Digital Signatures (2014-16), by Ashiq JA, Guillaume Forget, Peter Landrock, Torben Pedersen, Dawn M. Turner and Tricia Wittig 
  
• REGULATION (EU) No 910/2014  on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (2014) by the European Parliament and the European Commission
• Recommendations for the Security of Internet Payments (Final Version) (2013), by the European Central Bank
• Draft NIST Special Publication 800-63-3: Digital Authentication Guideline (2016), by the National Institute of Standards and Technology, USA.
• NIST Special Publication 800-63-2: Electronic Authentication Guideline (2013), by the National Institute of Standards and Technology, USA.
• Security Controls Related to Internat Banking Services (2016), Hong Kong Monetary Authority