‘Too many security devices’ has been the treasurers’ complaint about corporate-to-bank connectivity for many years. No-one questions the need for security when executing electronic transactions but there are few plausible options to replace the cumbersome system of multiple bank-proprietary tokens (their multiple formats), simply because no single alternative system has gained sufficient ground on the others to become the de facto standard.
PKIs, CAs and digital signatures: a brief explanation
Secure remote access to electronic and online financial systems relies on a process of identification and authentication. When transactions are made, a digital signature is required to authenticate the sender and to confirm that the message was indeed sent (assuring non-repudiation) and that it was not altered in transit (confirming its integrity). Secure digital signing relies on the encryption process.
The most common model of cryptography in this context is public key encryption (also known as asymmetric cryptography because it must have a corresponding private key). In the words of IBM: “Data encrypted with the public key can only be decrypted using the corresponding private key. Data encrypted with the private key can only be decrypted using the corresponding public key”.
Encryption uses an algorithm to generate a code (a ‘hash value’) that is almost impossible to break. Banks commonly use hash values based on 128-bit (bit is a contraction of ‘binary digit’) numbers which have a vast number of potential combinations (128-bit may now be considered the minimum secure value).
The broad system that manages public and private keys and which provides secure access to unsecure networks such as the internet, is known as a public key infrastructure (PKI). A PKI will typically include key depository and an independent certificate authority (CA) such as VeriSign, IdenTrust or Thawte, that issues and verifies digital certificates. These add substance to the keys and are used to verify that a web server is trusted by the CA. The CA also issues personal digital certificates, often delivered in the form of USB keys, and will confirm their validity (or otherwise) when these are used to gain access to a secure site. A PKI also includes a registration authority (RA), such as a bank, to verify public key users (eg its clients) for the CA before a personal digital certificate is issued and its associated key is activated.
For a bank client to use a registered personal digital certificate, two-factor authentication is often used. This requires ‘something you have, plus something you know’. In this case the ‘have’ would be the security device, such as a USB key, and the ‘know’ would be a PIN-type code.
What are the security choices?
In terms of how financial institutions enable authentication and validation, the choices are few. Banks may use their own proprietary set-up, offering secure ID tokens which may be physically connected to a computer (such as a USB device) or be offered as a standalone one-time pass code generator (as used by many online consumer banking sites).
There are some advanced technologies being used that take the USB token to the next level, such as Barclays Corporate Banking which, from 2015 will be offering UK clients a compact biometric device which can read and verify the users’ unique vein patterns in their fingers. This is still essentially a two-factor authentication tool but it takes the form of a personal scanner, using infrared light to detect the vein pattern in a living finger and so the authentication factors are rolled into one; nothing else is needed. It matches the pattern with that of a digitally captured and encrypted version previously recorded and stored by the user on a SIM card. Michael Muller, Head of Cash Management at Barclays Corporate Banking told Treasury Today at the launch of the device that he saw it as “an important part of our digital strategy” and was “optimistic” that biometric technology will join the mainstream fight against fraud.
Other banks opt to work with third-party providers such as IdenTrust (which was originally formed through bank co-operation but is now commercial). By far the most common form is the USB device and treasurers will often have one for each bank they work with. The much-talked about drawer full of devices is no myth; it is an awkward fact of making secure transactions.
If treasurers just want to make sure those transactions are secure, Andrew Burns, Director of TMS system vendor, Kyriba UK, notes that from a process standpoint, life has become more complicated as organisations start to centralise their payments processes (via a shared service centre for example).
Within a decentralised structure, payments could be issued and released at a local level, executed perhaps by a local Finance Director via an electronic banking platform. “When the payments requirement has been centralised, suddenly there are individuals responsible for multiple approvals for multiple banks,” he explains. This is where the problem of multiple security devices arises; having 30 different tokens in a drawer is not uncommon. If the holder of those devices is travelling, all those devices have to go along too. “It’s just not practical,” he states.
The challenge therefore is to find a practical alternative, and Burns believes that although “nothing has gained critical mass”, SWIFT’s 3SKey is making most headway. “It uses the SWIFT infrastructure which is a trusted banking network independent of any individual bank security method,” he notes. “I think the main worry for banks which are driving these security measures is that they do not want to outsource their KYC process, relying on authentication by somebody else’s processes in the PKI that they use,” says Burns. This is not necessarily the issue for 3SKey but he feels that many companies will not move until they know where the market is going. “They won’t invest money in a product and move away from their existing one if that’s not going to be the solution that sticks around.”
Without momentum, it will be difficult to get going. “For a treasurer, if too many of your banks are not registered for 3SKey it becomes difficult to use that methodology; it dilutes the value proposition if you still have many tokens plus the 3SKey.”
The main contender: SWIFT explains 3SKey
The hierarchy of security system sees SWIFT effectively as the neutral third-party infrastructure provider, the financial institution as the service provider and the corporate client as the customer, with individual employees as the end-point. “3SKey is all about personal not organisational-level digital signatures,” explains Neil Gray, Senior Manager for SWIFT’s Corporates Business in the UK and Ireland. The first stage of the process involves that individual receiving a token (in the form of a USB) from his or her service provider. Currently, the banks subscribing to the 3SKey service will order a stock of these tokens. The banks will issue tokens to their corporate clients and the client will distribute one to each employee in treasury or AP/AR as required. At this point, the token needs to be activated. This is done by plugging it into the USB port of a computer and accessing via the internet (not the SWIFT network) the relevant 3SKey portal where the activation button is presented.
This generates a digital certificate on the token; SWIFT is acting as the CA and as such has no direct relation with the corporate or token user. The next stage is for the individual to register the token (either in person or online) with each of the different banks on the corporate’s panel (assuming that they are subscribed into the 3SKey scheme); the banks here acting as the RA. This pairs the individual’s identity with the certificate on the token. “There is no hierarchy of banks in registration or use; they are all completely independent of each other,” comments Gray.
The registered token can be used to digitally sign in a variety of ways for different channels, such as signing and sending a batch payment file via the SWIFT network or a bank’s proprietary host-to-host system or as a means of authentication on a bank’s online portal. In each scenario, the bank is able to automatically revert to SWIFT (as the CA) to check the status of each certificate being used, enabling it to either execute or deny the request being made via the token. If an activated token is lost or stolen, Gray points out that the two-factor authentication system it uses would require anyone trying to use the token also to know the associated PIN.
The only limitation the USB-based 3SKey currently has is with mobile devices that do not support a USB port.
The only limitation the USB-based 3SKey currently has is with mobile devices that do not support a USB port. “We are conscious that treasurers are building mobile devices into their operations,” Gray comments. “We are actively working on an extension to support mobile platforms as well”. Details of the exact nature of the solution are not yet announced.
However, the use of 3SKey is not restricted to banking, having potential for example to extend into the space occupied by online trading portals or cloud-based financial platforms, says Gray. “This gives a stronger login access and when a customer wants to execute a transaction, the system can prompt the user to re-enter the PIN, effectively acting as the user’s signature to the deal.”
The roll-out status of 3SKey (as at August 2014) shows 38 bank subscribers (generally at group level, so including support across multiple countries). Currently, its reach is 113 countries. Around 51,000 tokens have been distributed, with 21,000 active users across some 4,300 corporates. SWIFT claims 17 of the top 20 cash management banks globally support 3SKey. “Typically corporates will start off in one business context before approaching their other banks; they are pushing their other banks to support it if they aren’t already subscribed. A bank that has newly subscribed to the service to support one might then question why it continues to support its own proprietary technology. This is something we have seen with Societe Generale.”
Using 3SKey: the bank view
Societe Generale is indeed one bank that has successfully adopted 3SKey as its sole security measure in the context of its Sogecash Web portal and host solutions. It started rolling it out in 2010 and is so convinced of its merits that this year the bank has announced to all clients that it is replacing its PKI proprietary solution with the single 3SKey device. Although there was no choice in the matter for clients, the response has been positive.
“We were looking for a multi-bank solution because when we discussed this with treasurers they quite often told us that they had too many security devices to manage for all their banks,” says Emmanuelle Fischer, Head of Marketing & Products for Payments and Cash Management, Societe Generale Global Transaction Banking. “We found an easier and cheaper solution for corporate clients that could be used with many banks and which is also compatible with most of the products we offer to them.”
Societe Generale has been very proactive in its approach to 3SKey. “I think there is a trend towards adoption and I think treasurers will be pushing their banks to deliver a single solution,” she explains, adding that there is some movement by the European Commission to work towards harmonisation of security devices.
“The only drawback with 3SKey is that you cannot plug it into a mobile device,” comments Fischer. “We have to go along with the trend of the past few years that sees more treasurers wanting their cash management applications on their smartphone or tablet computer.” Societe Generale has therefore been developing a solution for mobile devices, seemingly as SWIFT is also considering such a proposition but the bank clearly working towards its own more pressing commercial launch date. “Almost one year ago we launched our first cash management application for mobile; we will launch a new version later this year that will allow treasurers to validate transactions on their mobile devices and for that we needed to work on our own security solution.”
Mobile issues aside, Fischer sees a steady growth of the number of users. “We are confident that it will become one of the standards for all global digital signatures, to authenticate users on web portals and to sign all files when sending them to banks. But I think there could be additional applications for all digital contact with banks. Our clients are increasingly sensitive to security issues and although some see these devices as a constraint, many more are seeing the benefits.”
Whilst she feels SWIFT probably initially saw 3SKey as a tool for large corporates to sign orders on the SWIFT network, Fischer sees more mid-sized companies adopting it, with all users exploiting it beyond that network. “In our case, it is used to authenticate customers on our web portal, allowing them to make any transactions, but it is also used for other protocols such as FTP, SFTP and, in France, EBICS TS.”
Using 3SKey: the corporate view
Although French engineering and technology consulting company Alten has been connected to SWIFTNet since 2008, many of its subsidiaries outside France remained linked to their banks through e-banking services only. The growth of its business led to an increase in the complexity of systems and the number of banks its treasury needed to connect into. “This creates difficulties and is hard to maintain on both the functional and technical sides,” explains Guillaume Peslin, Global Treasurer of Alten.
When in France, the ETEBAC 5 corporate-to-bank communication platform was replaced by EBICS, corporates could no longer digitally sign payment files which were then verified by the bank upon receipt, the problem was magnified. “When SWIFT launched 3SKey in 2010, we immediately saw an opportunity to reduce the complexity of e-banking identification,” he says. Alten’s treasury department implemented the solution to work with Societe Generale’s ‘Sogecash Web’ online banking portal. “Now, when we update our authentication process, 3SKey requests all bank systems to facilitate the maintenance; this was done previously with a single ETEBAC card for France,” adds Peslin.
For any security solution to become a compelling proposition for the wider business community, it needs to be able to replace most or all other forms of security device; in short it needs to be the de facto standard. Getting banks to agree on anything is never an easy option.
Having used 3SKey for some while, he believes it “could also be a good tool to facilitate eBAM” (electronic bank account management), which Alten is now aiming to adopt. Despite its apparent flexibility, for 3SKey to move forward, Peslin notes one essential requirement: “the compliance of banks and their systems is key”.
A call to action
For any security solution to become a compelling proposition for the wider business community, it needs to be able to replace most or all other forms of security device; in short it needs to be the de facto standard. Getting banks to agree on anything is never an easy option. This appears to be the issue with moving the whole security aspect of corporate online banking away from that drawer full of single bank proprietary tokens towards a unified model of identification and authentication.
3SKey seems to be the current favourite; most banks (certainly those offering transaction services) are already on the SWIFT network anyway so it is a small step for them. For it to become the standard, Burns suggests that banks need “a bit of a push” from their corporate clients. “The technology goes in the direction of where the pain is; if treasurers can go to their banks and say they need a better solution then the banks will start to move,” he says. “But banks are so inundated at the moment with so many different demands – not least by the regulators – that they have to prioritise. If corporates do not raise the issue of security tokens then the banks will not move.”
