By Pawel Bulat, Product Manager at Comarch

In the previous article, I tried to answer the fundamental question of why anyone would need a token. Today, we know we need it in order to keep our money safe. It is a good time to reflect on some token-related problems and try to come up with a solution.

We will address those problems both from the production and usage sides, which, despite conventional wisdom, have quite a lot in common.

Security, by its very nature, is an uncompromising concept. Something can be either comfortable or secure. This can be seen very clearly when you take key less car starter systems. Since these solutions appeared on the market, car theft has become easier and quieter than ever before (‘relay theft’). This is the first proof that security does not go hand in hand with convenience. With some effort, however, one might find some compromises and optimizations to keep user experience at the proper level.

Working for many years with systems related to bank transfer authorization, I have learned that the simpler the technology stack of a given solution, the better. The comfort of the end customer is also the comfort of the banking service provider, and this in turn has it ramifications for tech vendors as well. Again: the simpler it all is for everyone, the better.

In order to understand this interconnectedness, let’s go back in time about 10 years and see how the simplest applications allowing you to make an online transfer using your smart card were built. These still look very similar today despite the passage of time. It is worth noting that smart cards (supporting the RSA cryptosystem) were the first widely available tools for creating signatures in banking applications. Their popularity results from their small size ease of use and low price. They are still widely used in most banks.

Technology-wise

The general work principle of a transfer signing mechanism is very simple. On top of the chain there is a browser which allows you to collect necessary data from the customer and forward it to a cryptographic card. The received data is signed on the card and transferred together with the original transfer document to the bank. The software on the bank’s side is to verify that transaction data has not been altered by unauthorized persons along the way.

At first, card-browser communication was quite complicated. The main reason for this was the fact that back in 2008 there were no mechanisms in place allowing that. Even today, such an option is only available to a limited extent.

But then, browser extensions came to the rescue. They were like a conduit allowing you to receive data from the browser and forward it down towards the card. It should be remembered that the providers of dedicated solutions also had to deliver an applet and a library for communication that would be compatible with, say, the pkcs11 standard enabling the very communication.

The core of the system was a microprocessor card powering the applet, i.e. a small program that was able to receive and handle incoming requests. At the very end, the sender would get a reply, e.g. a signature. In simple terms, this is the layered architecture of such a solution:

Up until now, the whole thing looks clearly, we have five layers.  One basic problem remains to be solved: at least four web browsers need to be supported. This means that we have to support two types of APIsat best. To top it all off, it has to be done on three different operating system families:

Windows,

Linux,

OS X (where further APIs will appear).

A universal applet written in the Java language could be a solution to the problem, but in this particular context the technology generated too many persistent problems. Now, this is where a simple thing gets quite complex. Every small update requires that all components of the solution are delivered to the customer in appropriate versions. This means further costs incurred by the bank and related to launching the environment update, testing and providing customer service.

What does this mean for the end customer?

The customer must ensure that the solution works properly right from the start:

• the appropriate extension is installed in the browser,
• the software for the middle card layer is in place (installing the relevant libraries),
• the required runtime libraries are not missing.

It should be remembered that a microchip the user has will work only in a configured browser, in a system with all product components installed. A simple installation process can become an annoyance for the user at some point, and even worse, they become dependent on a specific end station and browser.

The browser dependence may be especially problematic, because it is in browsers that security gaps are most often detected. This means that, security-wise, independence in this area is desirable. Problem diagnosis is also a challenge because it is difficult to identify quickly which module is affected.

In 2014, browser manufacturers understood that extensions are a solution looking for a problem. Most often they were the cause of unstable browser behavior. That is why Firefox, Chrome, or Opera discontinued their support for extensions. Thus, applet and browser plug-in users (including microprocessor card owners) were forced to go with Internet Explorer, where ActiveX controls were still in operation.

Solution

Once the support for extensions was gone, integrated APIs enabling communication with peripherals were to be turned to as a workaround. However, the works on these solutions kept dragging on. Comarch proposed its own tool called CCP, where the communication between the browser and the card driver components were made via a local server of sorts, thanks to the CORS (Cross-Origin Resource Sharing) technology.

This was the first step we had taken towards becoming independent from web browser manufacturers, and, as the time shows, a very right one. Today, the CCP solution is offered with cards and enables the users of older cryptographic devices (microprocessor cards) to work comfortably with almost all web browsers.

Our subsequent experiences in the field of building technology devices and dedicated solutions for online banking security brought fairly quick results. As early as in in 2015, the first prototype of a device talking directly to a browser appeared. As if that wasn’t enough, the device worked with any browser, on any operating system – without additional software. The device’s further simplified layer architecture is shown below:

The concept of building the said device, called tPro ETH, is to some extent the idea of CCP transferred to the hardware level, and the first solution of this type in the world supporting all web browsers. The user only needs to insert the device into the USB port in order to make transfers securely (the device uses drivers built into the operating system).

In 2008, no one even dreamt of a solution that would allow such convenience while maintaining the current level of security. Ten years later, we madeita reality.

Today, tPro ETH is offered as one of the possible solutions for online banking, and its integration requires only the use of a dedicated JavaScript API. The customer can use any computer equipped with a USB port.  The technology stack has been radically optimized while the solution generates fewer errors due to its simpler architecture.

The user should not be restricted or hindered by security measures. Independence, comfort, security – once I thought it was impossible to combine these features. The path taken by cryptographic devices over a period of 10 years is a path from dreams to reality. We look forward to seeing what the future holds for us.

Paweł Bułat, Product Manager at Comarch

Paweł is an expert with strong experience in the cyber security domain. For over a decade he has been gaining the experience in security solutions for online banking, based on strong cryptography. He has developed security extensions for web browsers and coordinated works over ECC Hardware Token (software and hardware layer). Currently, he is a Product Manager of Comarch Transaction Protection (tPro).