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
frameworkEven 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 riskThe 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 onThe
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 fitThe 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 integrityThe 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-RepudiabilitySSL
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.
ConclusionSecurity 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