Posted 7 months, 1 week ago
Let’s say you’re a pizza delivery person showing up at someone’s home: you expect him to pay for the pie you’re delivering, but when he opens the door he claims that he never placed an order and won’t accept the delivery. If the order was placed over the phone, there’s not much you can do. Someone might have spoofed the phone number in order to perform a prank, and there’s no real way to prove who actually placed the order. Luckily, the order was actually placed via a delivery app—meaning that the recipient had to sign in to an account associated with his address and credit card. Once you pull up the app on you phone and show the nogoodnik a record of the transaction, the jig is up, and he’s forced to pay out.
If it’s a matter of some cash for takeout, your ability to establish non-repudiation for these charges, isn’t such a big deal. If you’re a bank or financial institution dealing with millions of dollars in international transfers, on the other hand, non-repudiation is a matter of the utmost importance. If you’re monitoring money transfers to and from other banks via the SWIFT network, for instance, you need to be absolutely certain you can correctly assign each message to the correct bank. Not only do you assign an identity—you need to be able to prove it.
In addition to making obvious business sense, this is also a requirement for SWIFT CSP compliance. This means that banks need to find a way to ensure non-repudiation without breaking the bank or gumming up the inner workings of their back-office dataflows—and any solution they’re considering for security needs to be able to facilitate those non-repudiation checks.
Since our pizza delivery analogy was a bit whimsical, let’s take a second to offer a real definition of non-repudiation as it relates to banking and financial services. NIST offers the following definition: “Assurance that the sender of information is provided with proof of delivery and the recipient is provided with proof of the sender’s identity, so neither can later deny having processed the information.” From a practical perspective for banks and financial institutions, this means being able to go back into your logs and make sure that any transactions that were carried out were, in fact, the results of legitimate financial messages that weren’t tampered with or altered. In other words, non-repudiation involves finding some way to ensure:
While many discussion around encryption-management, for instance, tend to center on confidentiality (i.e. that no one but the intended recipient can read a given message), these other facets are just as important when it comes to preventing the kind of fraud that resulted in the infamous Bangladesh Bank heist and many similar incidents over the past few years.
Again, ensuring the authenticity and integrity of all relevant message-flows is the only way to be sure that you’re offering strong non-repudiation protections. In the pre-digital era, non-repudiation efforts were mostly accomplished through signatures (e.g. on a check or money order). For added levels of security, you might require that a particular signature be notarized, i.e. verified by a trained third party who was present at the time of signing. Of course, nowadays we realize how easy it can be to forge a signature—and most modern banking happens online, which means that physical signatures are being replaced with digital ones. If you’re a bank or financial institution, you know that not all digital signatures are equally robust. A signature box on an online form that requires you to drag your mouse to create a signature, for instance, isn’t going to provide much protection against forgeries. A system that uses asymmetric encryption to “sign” messages (you provide a signature with your private key and the recipient uses your public key to ensure that it’s really you), on the other hand, makes the signature impossible to forge unless an attacker has somehow gotten a hold of your private key.
Simply put, if the banks involved in the Bangladesh Heist had had an encryption solution in place, then by monitoring for non-repudiation compliance the banks would have been able to see the broken encryption signature, and the integrity of the message would have been rightfully called into question. Thus, the multi-million dollar heist could have been stopped in its tracks. Of course, actually stopping the transaction would depend on having a solution that offered both encryption management and regulatory monitoring with a compliance-centric interface.
As with so many things related to SWIFT CSP, compliance is often easier said than done. Banks need to be able to create and examine a reliable paper trail for all of their SWIFT transactions—they need to be able to go back into their logs at a moment’s notice and see:
Strong encryption and signing protections can help to connect messages to particular identities and ensure their integrity (i.e. that they haven’t been tampered with), but not all encryption is created equal. Not only do you need to be able to easily implement that encryption end-to-end across all systems that touch the SWIFT network (a process that can easily lead to high TCO if you choose the wrong solution), you also need to be able to read those encrypted messages without breaking the encryption in order to successfully perform non-repudiation monitoring.
Right now, if banks want to ensure non-repudiation compliance for its SWIFT message flows, they mostly have to rely on SWIFT itself for help. While this might work in some circumstances, it can quickly become cumbersome—and it doesn’t, by itself, provide any actual message-level protection the way that encryption does.
This challenge might lead some banks to work with a trusted third party for monitoring—but this can present its own problems. Essentially, you’re being asked to place your trust in a company based on its word and little else. Often, this is a black box encryption mechanism that could have undisclosed flaws or backdoors that would increase your risk.
Okay, let’s say you’re on board with the idea that encryption of SWIFT messages end-to-end is the only viable solution for complying with SWIFT CSP requirements and maintaining the authenticity and integrity of your messages. What’s next? How do you get around the encryption and key management headaches that we outlined above? For starters, you need a solution that effectively covers all of your endpoints; if your SWIFT messages are being encrypted at the moment they leave their points of origination, only to be decrypted before they’ve actually made it to the SWIFT network, then the messages are still vulnerable to tampering. This means that a heavy, complex installation that makes it difficult to cover all of your endpoints will present real issues, compared to a turnkey installation that immediately protects messages at the application level.
In addition to ease-of-installation, you’d also want ease-of-use from an admin, key management, and monitoring perspective. This is where automation can be a big help to banks trying to deploy a comprehensive encryption solution for the back office. Rather than relying on humans to keep track of keys or certificates and then change them out before they expire, you can opt for a system that automatically stores the keys and changes them out as needed, in addition to automatically encrypt every SWIFT message that's created and decrypt it as it reaches SWIFT’s systems. In this way, you avoid the potential pitfall whereby an encryption key expires, you suddenly can’t sign any messages, and your whole system falls into disarray.
Finally, you need to be able to go back through your logs to read over these encrypted messages without interfering with the integrity of those messages. Because of the nature of message encryption, this presents a challenge—the kind of challenge that many would try to solve with a backdoor that would ultimately decrease your security. Instead, you need a solution that offers regulatory and non-repudiation monitoring via a proxy server that ensures the integrity (not to mention confidentiality and authenticity) of the actually messages in transit.
Right now, p≡p for SWIFT is the only solution that offers complete SWIFT CSP compliance by way of automated end-to-end encryption. Following a turnkey installation, you simply plug and play: p≡p’s decentralized system automatically encrypts your messages without any effort on the admin’s part, signs its with a private encryption key, and then decrypts it in transit until it reaches the SWIFT network. Because it integrates with all of your existing back-office systems and your PKI systems (if any), it offers a low TCO both in terms of upfront cost and installation and maintenance. Using perfect forward secrecy and short-living keys, p≡p is able to keep your attack surface to the absolute minimum.
At the same time, p≡p offers easy monitoring and non-repudiation compliance by way of a proxy server and read-only encryption keys. This means that you can easily look back at your audit logs to associate particular messages with particular identities, ensure the integrity of those messages without breaking their encryption signatures, and ultimately establish non-repudiation.
At the end of the day, this provides the only end-to-end method for ensuring the confidentiality and integrity of your SWIFT messages. As such, it represents the best option complying with SWIFT CSP’s non-repudiation guidelines—since there will never be any doubt about where the messages in your message flow really came from, or if their contents were never altered in transit. For banks that already have extensive anti-fraud IT systems in place, this is a mission critical component—for banks that don’t, this is true turnkey security.