Case Study: Internet banking services

Feature

Case Study: Internet banking services

Companies must instigate their own security arrangements for Internet transactions, if they are to retain customer confidence

Secure Internet banking incorporating encryption

Traditional customer access systems have operated in closed private networks accessed through dedicated telephone lines; banks and their customers were happy to use these services as long as certain core data security concerns were allayed. These data security requirements were usually described in terms of the need for confidentiality, integrity and authentication.

The need for confidentiality, which is of particular importance in the corporate banking arena, prescribes that data cannot be interpreted by anybody other than the sending or receiving parties. The confidentiality of computer data can be easily protected through a regime of data encryption.

Sometimes data will be deliberately or accidentally amended during transmission and it is common practice therefore to use cryptographic methods to be able to detect these amendments. These techniques, known as Hash or Message Digest functions, are a very reliable means of guaranteeing data integrity.

Whenever the communication is between multiple parties there is a further requirement for guarantees that each entity is "who he says he is". A further encryption process, based on public-key cryptography, allows each user to apply his own digital signature to a transmission so that it can be said to be authenticated. Often the digital signature process is augmented by the use of digital identity certificates "signed" by a trusted Certification Authority. A Certification Authority is a component in a Public Key Infrastructure or PKI.

One popular rule of thumb is that "when you are connected to the Internet, the Internet is connected to you...". For this reason, many Internet applications assume the presence of the data security precautions described above, but even where systems can guarantee data security they often fail to legislate for when something actually does go wrong.

For example, because of the ubiquitous nature of the Internet, there is the theoretical possibility that anybody anywhere can attempt to attack an Internet banking service; these attacks can manifest themselves in the form of traditional break-in attempts, fake websites or by "denial of service" attacks.

Legal framework

Even where Internet Banking Services can be secured by cryptography, authenticated websites and firewalls, there remain serious legal challenges to be resolved.

Business on the Internet is without precedent and lacks a legal framework in most countries; banks and customers therefore need to define appropriate legal measures covering, among other things: Service Levels, Indemnities, limitations of liability and acceptability of digital signature. Essentially, it is imperative that they legislate for when things can go wrong, so that both parties can understand their obligations and entitlements.

By its very nature, however, the Internet has no defined jurisdiction; in legal parlance this is sometimes described as being "extraterritorial". Users are increasingly mobile and some countries even apply local national regulations governing the use of cryptography, so it is therefore important for all parties to acknowledge these constraints in their agreements and to define the operational and legal jurisdiction under which Internet banking is supported.

In conclusion, the Internet poses a number of security challenges for banks willing to invest in it, but only with an integrated set of proven security technologies, professional policies and procedures and an educated user base can a bank achieve a successful deployment.

Applications at risk

The are many types of banking application that are now in the process of migrating from these traditional closed network environments to the more open and exposed medium of the Internet. The migration and evolution of e-commerce systems on the net has itself prescribed the need for an entirely new vocabulary to describe new technologies such as Virtual Private Networks [VPN's], firewalls, extranets, proxy servers, Secure Sockets Layer [SSL] and so on

Among the first tranche of banking applications that can use these technologies and augment them with the implementation of cryptographic solutions are:

( Corporate Electronic Banking Systems

( Home Banking Applications

( Ancillary Services, such as FX trading, Trade Finance, Portfolio Management and so on

The technology already exists for other ATM-analogous applications, such as cash downloads, lodgements and video conferencing. There are already some working implementations in production. However, for the sake of simplicity it is best to focus on implementations that are familiar to many of us.

For instance, consider a hypothetical transaction where an Internet user initiates a transaction to pay a large foreign currency cash value to a beneficiary.

The transaction must remain confidential now and for a long time in the future, as if it was made at the branch. The data content must have integrity [i.e. not changed in transit]; both parties need assurances that critical data such as the transaction value or beneficiary account details are as originally entered at the client end.

The bank will require absolute assurances that the initiator of the instruction is authentically who they purport to be. The bank will require the presentation of some form of electronic authentication, analogous to an identity document that might be presented under normal "paper" circumstances.

The value amount of the final transaction might be affected by a fluctuation in the currency market after the instruction was issued; this fluctuation could work in either parties favour but it defines the need for both parties to be unable to repudiate either the payment or its receipt. This requirement defines a need for the sender and bank to digitally sign their messages.

Now consider a retail customer paying a domestic bill or other low-value payment to a pre-mandated beneficiary over the Internet:

Does it matter whether this transaction is confidential or not? Not necessarily.The data content must have integrity, but in this type of transaction the user must select a (pre-mandated) beneficiary account, so the potential to amend this detail is greatly reduced.

The need for authentication of the payee is not so great; after all, transactions of this nature are typically of low value and, given the nature of the application, the end-user does not care if some impostor fraudulently pays their bills! The payment is of relatively low value, is typically in a domestic currency and is unlikely to be repudiated; a digital signature might represent a barrier to the overall user-friendliness of the solution.

The solutions - cutting your cloth to fit

The more "traditional" applications listed above all have a requirement for confidentiality, integrity, user-authentication and non-repudiation, but banks attach different degrees of importance to each, depending on the attendant risk as a consequence of the value of the asset being protected and of the level of associated liability.

In Internet browser and server products there are technologies embedded that transparently enable cryptographic software or that allow the implementation of "plug-in" solutions. I will discuss the possible solutions under the headings listed at the beginning of this feature and then suggest one feasible solution that provides "Security in an Open World".

1) Confidentiality and integrity

The security solution embedded in internet browsers and servers is called Secure Sockets Layer [SSL]; among other things it encrypts and hashes all traffic, thus providing a high degree of confidentiality and integrity to both parties to a transaction.

2) Authentication and Non-Repudiability

SSL can provide server and client authentication through the deployment of digital certificates issued from within a PKI and stored in the client browser. There are certain disadvantages to this model, namely:

The digital certificates are attached to the software and not to the end-user. Therefore there is the absence of the concept of a digital signature that is bound to the end-user and as a consequence it is not feasible to provide an authentication framework for multiple users at a single [PC] browser. The certificate in the browser is not easily portable, for instance for use at home and in the office the certificate

There is an accepted principle in the cryptographic industry that states that "authentication should be a combination of something you know and something you have". What this means in the context of Electronic Banking is that for a user to authenticate himself to a bank he should have something he holds [some form of token containing a digital certificate] and something he knows [a password or PIN]. To this end I would suggest that the most viable authentication models can be constructed using either:

3) User smart cards containing a signature key and certificate, protected by PIN and accessible from a browser plug-in or Java applet.

User "key ring" Files [on diskettes] containing the same signature key and certificate, encrypted and secured by a pass phrase and accessible from a signed Java applet in the browser. This is arguably a less elegant solution, but for a very large community of users it can be highly cost effective and negates the requirement for a card reader on the Client PC.

Conclusion

Security is often a trade-off between what is acceptable and what is affordable. Also, any security solution should strive to be as transparent as possible so that users will not resist its implementation.

"Security in the Open World of the Internet" is very complex and its deployment is not a trivial exercise that should be embarked upon without at least seeking expert advice. Baltimore Technologies are available and have the expertise to offer a consultative service to you in order to help you to define a sensible framework for your Internet Banking applications.

Compiled by Mike Burkitt


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in October 1999

 

COMMENTS powered by Disqus  //  Commenting policy