Core banking systems do not usually provide cryptography services (encryption, decryption, digital signatures, private and public keys, etc), as it is mostly some other systems’ domain and not the core, transactional one.
So what to do when you actually must address it?
One of our clients turned to us with exactly such a requirement – during an initial call with them, we learned that they would need to implement digital signatures in the Profile core banking system. They were forced (by a security audit they periodically ran) to introduce some extra security measures within their entire chain of systems that process their outgoing payment records and Profile was part of the chain. The idea of securing data using digital signatures has been in use for quite a long time, but that rarely happens in the core systems. It may happen in the front-ends, APIs, external apps etc… but not the core transactional system, which should be pretty much independent from all that complexity. Initially we were surprised when such a requirement arrived, but after receiving detailed explanations from the client, on how a few million dollars can magically escape everyone’s attention and land in a faraway country (with e.g. a little help from an administrator who decided to not to continue his current job and to move to a distant isle), we weren’t anymore.
Profile doesn’t handle much as far as encrypting goes, apart from the usual tasks related to login information, user name, password etc. Encrypting or digitally signing payment records in our good old system sounds slightly exotic and even more so when we realized what such an approach entailed. After some analysis, we understood that we’d need a comprehensive and robust solution, and the version of Profile the client had didn’t seem to offer one. How to store the private and public keys? How to move them and maintain them without jeopardizing their safety? How to optimize the future maintenance of the solution, SLAs and other things? The number of questions rose exponentially the longer we scrutinized it.
Let’s try to highlight the most important aspects that need to be addressed when introducing encryption to Profile;
Where to start?
Profile has been offering libraries to encrypt/decrypt data for at least 25 years. But unfortunately, those libraries, even though workable, were not useful nowadays on account of their dated constraints: for example, they did not let you control the lengths of private and public keys, nor were they conducive to managing digital signatures. Luckily Profile 7 came to the rescue, allowing for more options and flexibility with regards to encryption and digital signatures.
Encryption vs Digital Signature
Digital Signatures, unlike regular encryption, starts by using the private key to encrypt the data used for the signature, and later the public one to verify it.
Where to store private and public keys
Even though you may be good to go with the encrypting and decrypting in Profile, you will need to figure how to provide enough of security for storing your keys. There are tools available for that and they should be carefully reviewed and accepted by your security team. There’s a chance that an existing solution, implemented in other systems in your institution, will be appropriate to be reused in Profile. Therefore it is recommended to check what’s available in your systems prior to making any decisions.
OpenSSL
There are millions of implementations of encryption algorithms. You shouldn’t worry about creating anything from scratch, but instead, just pick the right implementation and incorporate it. For instance, the OpenSSL implementation can provide adequate tools for your encryption needs. When you finally choose something, it’s important to figure how the private keys can be safely transferred from one place to another – you should avoid saving such sensitive data in temporary files etc.
Performance
Core banking systems process vast amounts of data, and it is likely that when you need to introduce a solution that encrypts data, regardless of the goal, your solution will need to be performant. Sometimes we’re talking about batch processes that handle millions of records and require running an equal number of encryption processes. In Profile 7 you should be good to go – with an ability to execute at 1-2ms per single process.
Going through all the technical aspects of encrypting Profile data, we learned a lot about taking proper security measures and how small differences in Profile artifacts can have an impact. Furthermore, we were also fortunate to be able to consult with security experts who helped us conform to industry standards, finally delivering a solution the client could rely on and trust.
Let’s sum it up, Profile doesn’t provide too much support when it comes to encrypting. You will have to trust some existing implementation of the encryption algorithms you’re interested in and enable calling it from Profile. Fortunately, newer Profile and GTM versions provide the libraries that will help you. Please don’t hesitate to contact us should you need any support with your Profile system.

