Where 2FA and PKI Meet

Under pressure from sophisticated attacks and rising fraud, many B2C organisations of the financial industry are currently enhancing the static password based authentication to their web applications to something stronger - the 2FA age. 2-Factor Authentication (2FA) is currently achieving large scale deployments and consumer adoption where PKI failed a few years ago.

From a technical standpoint, PKI offers significant benefits including the possibility to sign transactions of legal value in domains of trust, which is key to financial institutions offering online services. Yet, 2FA technology, which offers mere user authentication, has been preferred by most players for its user-friendliness and ease of deployment.

The Challenge Ahead with 2FA

The main driver behind the success of 2FA is the protection of online applications against crimes of ID Theft. An important feature, which 2FA does not address at present, is the possibility to offer electronic signature capability, which is gaining more importance due to the need for message integrity as Man-In-The-Middle and other advanced attacks are on the rise.

Traditionally, Secure Signature-Creation Devices (SSCDs) are either chip-enabled cards or USB-connected tokens. Both of them need to be connected to an end-user station and this is where the nightmares start for most IT staff departments. Experience shows that there are often drivers missing, broken connections or restricted administration rights. In retail, it is simply impossible to control the environment of the end user. It is therefore not a viable option to bring such signatures devices to a large audience.

A Method to Remedy the Situation and Leverage the 2FA Technology

Our method is very inspired from the cloud computing concept where a secure infrastructure that offers secure signature services is made available as a service to the Web community.

Our approach is to centralize the storage and management of private signing keys at trusted 3rd parties with highly secure environments and strict procedures in order to maintain data centres, that are both logically and physically protected. The user retains control over his private key using 2-Factor Authentication techniques. What we propose is in a sense very similar to the safe deposit boxes offered by banks. In such cases, the ownership of the deposit is not questioned even though the administration and access to the safe box is under the responsibility of the bank. Similarly, we propose to safe deposit the user's private key in a tamper evident environment whose access is granted when a 2-Factor Authentication of the end-user is performed.

How Does it Work in Practice?

In practice, a user is enrolled and his credentials, along with a key pair is sent to a certification authority. So far, the process is identical to a legacy PKI scheme. Instead of receiving the certificate and the key pair, the user receives two factors of authentications (e.g. a password sent from a PIN Mailer and an activation password on SMS using this media to send One Time Passwords in the future). The private key remains in the secure signature server its entire life and will never ever leave that server.

Once this initialization phase is completed, the end-user is ready to use his key to e.g. sign a transaction presented by a remote application.

A typical (and simplified) architecture is depicted in the figure 1 below:

Figure 1 - Basic architecture

To preserve mobility and keep end-user constraints as low as possible, our only assumption is that the user is connected to a web enabled application. The challenge therefore is to ensure that the data to be signed can be transmitted confidentially and integrally to the central signing server. While keeping minimal footprint, we have to introduce an end-to-end encrypted and authenticated channel to make sure that:

a. When a connection is established, the server can be sure that a legitimate user is in the other end, and

b. When the connection is established the user can enable the environment where his keys are available, and

c. The user's keys can only be available in the environment established by a 2FA process. The authentication mechanism does not really matter (SMS- based OTP, OATH based OTP, EMV based OTP or proprietary methods are supported). The ultimate aim is therefore to implement this as rigidly as possible such that it will not even be possible for inside server operators or even developers with access to server source code, to circumvent the protection once the system is deployed.

We wrote that item c is fulfilled by implementing a carefully designed security kernel at the server side. Items a and b are achieved using a security protocol which we have designed. From a top-level perspective, the protocol works the following way:

• The client receives all user credentials (password, OTPs, token output etc.) and combines these values with entropy (random values) to form a symmetric key.

• The server (more precisely, the security kernel) attempts to form the same symmetric key from the knowledge it has and from publicly exchanged nonces.

• Once the keys have been established, the client sends encrypted commands to the server and receives encrypted responses back from the server. If either party fails to decrypt a message, the communication is terminated. The key for a given connection is represented by the state of the Pseudo Random Function. Whenever the user authenticates himself using some credential (e.g. an OTP) this state is updated using a so-called pre-session key derived from the credential (in other words the effective key length is augmented using these credentials).

A convenient way to provide such signature services for the web application provider is to develop an application using a thin client in order to fulfil the common zero-footprint requirement mentioned above. In practice, this is made available as a Java applet running in a web browser. This applet can of course be customized to follow a given workflow with interactive features such as What You See Is What You Sign (WYSIWYS) functionality.

Conclusion

To summarize, I will present the key advantages of deploying such a method which, as presented in the introduction, leverages the benefits of PKI and 2FA.

• Convenience: Because a mere 2FA token and a connected terminal are the sole requirements for the end-user. The burden of PKI deployments (middleware installation, lifecycle management, etc.) remains transparent for the customer and is managed centrally. The application provider can customize his workflow and application taking advantage of the authentication and signing services provided by the trust provider.

• Security: Thanks to the secure protocol, the fact that the key storage is protected in a tamper evident environment and the strict administration procedures enforced at trust providers site(s), it is possible to reach a SSCD level and provide Qualified Electronic Signature (QES) services to key owners.

• Cost-efficiency: No other solution available on the market offers such a combination of value added authentication and signing services directly usable in B2C environments. The total cost per user remains way below legacy SSCD devices.

As of January 1st 2009, Cryptomathic has been granted a European Patent (EP 1455503) for this method implemented in the Cryptomathic Signer product.

Previously published in Cryptomathic NewsOnInk, 2009

Image: "MasterCard credit card", image courtesy of Hakan Dahlstrom, Flickr