Journal of Internet Banking and Commerce ISSN: 1204-5357
ISSN: 1204-5357
+44-175-271-2024By Javad Soroor, Electronic Commerce Division, Postgraduate Information Technology
Engineering Group, K. N. Toosi University of Technology
Web: www.soroor.ir, www.csicc2006.ipm.ir/AOSE/
Email: j_soroor@sina.kntu.ac.ir, soroorsoft@yahoo.com
Javad Soroor used to be with the Computer Science Department of Amirkabir University of Technology, Tehran, Iran. He is now with the Postgraduate IT Engineering Group, K. N. Toosi University of Technology, Tehran, Iran. His major is e-Commerce and business administration. His favorite areas of research include: e-Commerce, m-Commerce, SCM, and CRM. He has written more than 17 papers which were accepted by accredited international journals and conferences. His current research projects are: "The application of IT potentials for Mobile Real-time Supply Chain Coordination" and "Models for Financial Services Firms in Developing Countries Based upon Mobile Commerce".
Visit for more related articles at Journal of Internet Banking and Commerce
Modern fast-evolving technology is constantly bringing new dimensions to our daily life. In Iran, electronic banking systems provide customers with easy access to banking services. ATMs, phone banking, Internet banking, and more recently, mobile banking have considerably improved the interaction between user and bank. This paper discusses the security of today’s electronic banking systems in Iran. We focus on Internet and mobile banking and present an overview and evaluation of the techniques that are used in current Iranian systems. The best practice is indicated, together with improvements for the future. The issues discussed in this paper are generally applicable in other electronic services such as e-commerce and e-government.
Online electronic banking systems give everybody the opportunity for easy access to their banking activities. These banking activities may include: retrieving an account balance, money transfers between a user’s accounts, from a user’s account to someone else’s account, and retrieving an account history. Some Iranian banks also allow services such as stock market transactions, and the submission of standardized accounting payment files for bank transfers to third parties.
As technology evolves gradually in Iran, different kinds of electronic banking systems emerge, each bringing a new dimension to the interaction between user and bank. The Automated Teller Machine (ATM) is the first well known system that was introduced to facilitate the access of the user to his banking activities. The user can perform some of the transactions mentioned above via a graphical user interface. These are transmitted to the bank’s computer system with which the device has established a communication link. The next step was the introduction of phone banking. Iranian users can make a telephone call from home to the bank’s computer system, and can use the phone’s key pad to perform banking operations. The Internet offers a new alternative to the phone banking system. By means of a more sophisticated and user-friendly interface, a browser or a dedicated standalone application, people can use the Internet to connect to the bank’s computer system. Electronic devices are constantly getting smaller, while their functionality is extending. Now, mobile phones even offer the possibility to perform electronic banking in Iran.
This paper discusses the security of today’s Iranian online banking systems. It concentrates on Internet, i.e., WWW [2], and mobile, i.e., WAP [32], banking. This work is based on an extensive survey of the available online banking systems throughout the world, including Iran. The survey was based on publicly available information. It was focused on the user side of the system, and the interaction between the user and the bank. The security of the electronic banking systems of 7 Iranian banks and around 30 worldwide banks was investigated. This seven-member subset seems to be representative with respect to the security offered by all current Iranian online banking systems.
The paper is organized as follows. In Section 2, the paper starts by explaining the basic architectures of WWW and WAP electronic banking systems. The main security requirements in an electronic banking system are identified. The important balance of security versus cost is shown. The different services in an online banking system, which are related to the bank’s internal structure, are briefly discussed. Then a distinction is made between two important security aspects: while Section 3 discusses the security of the communication between client and bank, Section 4 elaborates on the additional client authentication issue. Additional security aspects are addressed in Section 5. Finally in Section 6, some concluding remarks are formulated. These include an indication of the current best practice in Iran, and some suggestions for future improvements.
Figure 1 shows the basic architecture of an Internet electronic banking system. There are two participating entities: the user and the bank.
Figure 1: Internet banking structure.
When the user has a PC with a network connection, the most common way to communicate with the bank is via a Web browser, hence banking through the World Wide Web [2] or Web banking. The standard protocol for communication between the browser and the bank’s Web server is then used. It is often referred to as HTTPS, which is the HTTP protocol on top of a security layer (see Section 3). HTTP is the communication language of the WWW.
A bank will mostly require more security functionality than an ordinary browser is able to provide. This extra security functionality included strong cryptography (see Section 3-6).
A dedicated standalone client/server application is therefore an alternative way to realize communication between the user and the bank. The same protocol as used by the Web browser/server can be used here to provide security. However, the bank must provide the user with the necessary software, as the electronic banking system does not rely on the browser that is already installed on the user’s computer.
To avoid the problem of distribution and installation of extra software on the user’s computer, banks often deploy an intermediate solution. An ordinary browser is used at the client side, but to increase the functionality, a Java applet is downloaded from the bank’s website. This applet is a relatively small piece of software code that runs within the user’s browser, and that will provide extra security functionality. A big advantage of this approach is that the applet technology allows the bank to easily maintain and update the client software. Clients will automatically download and use new versions of the software. Banks do not need to distribute new software in an old-fashioned way. Note that in the scope of this paper we intend to use the term ‘user’ when we want to refer to a physical person. With the term ‘client’ we want to refer to the machine and the software, as in the traditional client/server sense.
Figure 2 shows the basic architecture of an electronic banking system using the Wireless Application Protocol (WAP) [32]. There are again two participating entities: the user and the bank.
Figure 2: WAP banking structure.
When the user has a WAP-enabled mobile phone, he can connect to the bank via a wireless link. WAP is essentially a wireless equivalent to the Internet protocol stack (TCP/IP). To connect the wireless domain to the Internet, a WAP proxy or gateway is needed to translate the protocols used in WAP to the protocols used on the Internet. For example, the WAP proxy encodes/decodes the content to reduce the size of the data that has to be sent over the wireless link.
Just as for the WWW, the user interface to the electronic banking application is via a mini browser in the mobile phone. The communication between the mobile phone and the WAP proxy is secured with a protocol that is very similar to the one used in the Internet case (see Section 3).
A major difference in a WAP banking system is that there is no end-to-end connection between the client and the bank’s (Web) server. Banks should therefore not rely on the client’s default (and untrusted) gateway, but have their own trusted and secure gateway within a secure environment together with their server (WAP is currently often deployed over the bearer GSM – Global System for Mobile communications [31]. Switching from the gateway of the client’s provider, to the bank’s gateway can then for example be done by sending a Short Message Service (SMS) message).
The following general security requirements [22] also apply to electronic banking systems:
- Confidentiality ensures that only authorized entities have access to the content of the exchanged information. E.g., an eavesdropper should not be able to find out what transactions a particular user is executing.
- Entity authentication: users should be sure that they are communicating with the real bank, before sending sensitive information to it; banks should know the identity of a user before processing its transactions.
- Data authentication — i.e., data origin authentication and data integrity — allows one to detect manipulation and replay of data, by unauthorized parties; data manipulation includes insertion, deletion and substitution. E.g., users and the bank want to be sure that the information they receive is genuine and fresh (not replayed).
- Non-repudiation prevents an entity from denying previous commitments or actions. E.g., a bank should be able to prove to a third party that a user performed a certain transaction, in case that user denies having performed it.
Security measures are needed to prevent certain risks and associated costs to occur. The security measures, however, also impose a certain cost by themselves. A proper balance should therefore be made between the investments in security measures and the potential costs that a bank might have to cope with due to remaining risks without these measures. Particularly in electronic banking systems, the extra cost at the client side is reduced as much as possible. Users should be able to perform electronic banking with the standard infrastructure and software that is already available. This makes the electronic banking service more attractive, but might unfortunately have an impact on the security level this service can offer. In practice, banks try to have a minimal level of security alleviating most of the risks, with maximum level of convenience.
This paper focuses on the user side and the interaction between the Iranian user and the Iranian bank. Nevertheless, in order to provide additional insight in an electronic banking system, this paper briefly discusses the bank’s internal structure.
Let us consider a fictitious electronic banking system. Four major functionalities are present in our fictitious bank. As ‘separation of concerns’ increases the modularity, maintainability, etc., and as such security, these functionalities are implemented as four distinct services:
(1) To interact with clients, the bank requires an Interface Server. An interface is needed for all different environments: ATM, WWW, and WAP.
(2) The bank should verify the authenticity of client requests and should authenticate its responses. This is done by the Authentication Server.
(3) Financial transactions are validated by the Transaction Server. This server also provides an easy interface towards the mainframe.
(4) Finally, the Mainframe executes the transactions and keeps the financial records.
This structure reflects the different services that are present in any electronic banking system worldwide. The security of the communication between the client and the bank (as discussed in Section 3) is handled in the Interface Server part. The authentication of the user (as discussed in Section 4) is handled by the Authentication Server.
Note that it would be possible to rely on a third party to provide for example the authentication service. Microsoft’s Passport [28] is such a service that is intended to provide a single identity with which a user could perform all its online activities. Although this might work for some e-commerce merchants, authentication in an electronic banking application is far too critical to entrust it to another party.
In this section the security of the communication between the client and the bank is discussed. We restrict ourselves to the standard solutions that are used within almost all electronic banking systems, namely SSL/TLS and WTLS, for Internet and WAP banking respectively.
Secure Sockets Layer (SSL) was originally an initiative of Netscape. The IETF adopted SSL for its Transport Layer Security (TLS) protocol [4]. The WAP Forum adapted TLS to create a wireless equivalent, Wireless Transport Layer Security (WTLS) [33]. Detailed background information on SSL/TLS can be found in Rescorla [25]. Although there are differences between (several versions of) these protocols, conceptually they provide the same security service: a secure channel between client and bank.
SSL/TLS/WTLS provides a secure communication channel between the client and the bank. This means that the data that is transmitted between both ends is kept secret (confidentiality) and that tampering will be detected (data integrity); the bank is always authenticated; the client can be required to authenticate too. Note that many electronic banking systems do not rely on the client authentication feature of the secure channel, but rather implement a client authentication mechanism on top of this channel (see Section 4).
An advantage of SSL/TLS/WTLS is that it can easily be used underneath various communication protocols, including but not restricted to HTTP. As SSL/TLS/WTLS only provides a secure channel, it does not provide non-repudiation: at the receiving side, the transmitted data leaves the secure channel, and the cryptographic protection is removed; there is no digital signature on client data. Electronic banking systems should therefore implement a non repudiation mechanism on top of the secure channel. However, note that this is rarely done in practice.
A connection between the client and the bank is divided into two phases, the handshake and the data transfer.
The purpose of the handshake is three-fold [7]: client and bank need to agree on a set of cryptographic algorithms that will be used to protect the data, to authenticate each other, and to agree on cryptographic keys; secondly, they need to establish a set of cryptographic keys with which data will be protected; lastly, the bank authenticates to the client and, optionally, the client authenticates to the bank.
Once the handshake has been completed, data transfer can take place. Data is broken up in fragments, and transmitted as a series of protected records. To provide data integrity, a Message Authentication Code (MAC) is computed over a data fragment; fragment and MAC are then encrypted.
The first public version of SSL, version 2, suffered from a number of security flaws, which have been fixed in SSLv3. As browsers nowadays still support SSLv2, and as it is still in use in some systems, we briefly sum up its security problems [25]. The same cryptographic keys are used for message authentication and for encryption; this means that in export mode the security of the MACs is unnecessarily weakened. SSLv2 has a weak MAC construction and relies solely on the MD5 hash function; Dobbertin has demonstrated the vulnerabilities of MD5 in [6]. SSLv2 does not have any protection for the handshake; hence a person-in-the-middle attack cannot be detected. Finally, a truncation attack is possible, as SSLv2 simply uses the TCP connection close to indicate the end of data, so that the attacker can simply forge the TCP FINs and the recipient cannot tell that it is not a legitimate end of data [7].
The IETF TLS working group adopted the SSLv3 protocol. Some minor modifications were made to increase the security: the way cryptographic keys are expanded from the initially exchanged secret was improved, the HMAC-like MAC construction was replaced by the real HMAC [18] and, implementations were required to include support for the Diffie-Hellman key agreement [24], the Digital Signature Standard [10], and Triple-DES [9] encryption. The IETF TLS working group is at the time of writing of this article working on several enhancements to the TLS protocol, including (wireless) extensions, and new ciphersuites incorporating Rijndael [3], the Advanced Encryption Standard [11].
The WAP Forum has adapted TLS to make it suitable for a wireless environment with small devices, which have limitations on bandwidth, memory and processing [7]. WTLS therefore includes the usage of elliptic curve cryptography (limited memory and processing) by default; WTLS does also work on top of a datagram instead of a connection based communication layer (compare to UDP vs. TCP on the Internet); finally, WTLS defines its own certificate format optimized for size (limited bandwidth), but supports the ordinary X.509 certificate (see Section 3.5) too.
Today’s popular browsers used in Iran implement the SSL/TLS protocol by defaultTP PT. As already indicated, when presenting the basic architecture of an Internet banking system, many banks prefer to use their own (or a third party’s) implementation of SSL/TLS, executed from within the browser or via a standalone application. The main reason behind this was the existence of the US export restrictions (see Section 3.6).
As an alternative to the browser-based electronic banking application, a standalone application can be used which provides both the necessary security and the banking functionality. Sometimes a standalone application is only used as a proxy running on the local machine of the user, that sits in between the browser and the bank’s server, and adds strong security for the communication between the client and the bank (while the communication between the browser and the proxy remains weak). In many cases, program code including strong security and possibly banking functionality is just downloaded as an applet, and runs within the browser. This applet can again have complete functionality, or behave as a proxy in between the browser and the bank’s server.
The user can only trust the correct execution and interface of the electronic banking application, if he has a genuine copy of the browser or the standalone application. If a Java applet is used, this should be digitally signed with the bank’s private signing key [21], so that it can be verified by the user before actually executing it. Users must recognize when they have a secure session with the bank. However, in today’s browsers, there are only some limited visual indications (e.g., closed lock), and an inexperienced user is easily fooled by a spoofed website, as demonstrated by Felten et al. [35] and more recently by Yuan et al. [34].
Above all, there must exist a meaningful Public Key Infrastructure (PKI). A PKI ensures a correct mapping of public keys to entities. An entity’s name together with the corresponding public key is put into an X.509 [14] certificate which is signed by a Certification Authority (CA). The authentic distribution of ‘root’ certificates, the certificates of the CAs, is here very important. They are used by the bank to verify entity certificates (if client authentication is based on this mechanism; see Section 4). The client needs them in order to verify the bank’s certificate during SSL/TLS authentication, and in order to verify digitally signed applets. Authentication cannot be performed without authentic root certificates. Root certificates are usually included in the installation of today’s Web browsers. If the Iranian electronic banking system is based on a standalone application, a root certificate is usually hard-coded in the software, or put in a configuration file. In all cases, they are typically only protected by the operating system. Hence, if the root certificates on a user’s machine are replaced by fake ones, an attacker can impersonate the bank, without the client noticing it.
Providing a secure communications channel from a client to an authenticated bank is only part of a secure Iranian electronic banking system. Authenticating the client is the other crucial part.
An important distinction should be made between entity and transaction authentication. Entity authentication means that the client authenticates when initiating a session with the bank. Transaction authentication means that individual transactions within this session are authenticated by the client. Depending on the authentication mechanism, transaction authentication can provide non-repudiation of single transactions, while entity authentication does not provide non repudiation of transactions. This distinction is clearly made in today’s electronic banking systems worldwide. In some systems only entity authentication is present, while other systems incorporate transaction authentication too. Both entity and transaction authentication can be provided in various ways, as presented in the remainder of this section.
Fixed Passwords
Many electronic banking systems all over the world still rely on a fixed password to authenticate the client (two out of three in this survey). This password can be a PIN number or a character-based password, and is often combined with a service account number that is not easy to guess (i.e., unrelated to the user’s name or bank account). In many cases only a subset of the digits has to be provided by the user, which provides some security against an attacker who is looking over the shoulder or is sniffing the keyboard (the bank asks for a different subset each time).
Fixed passwords are very often used for entity authentication. In rare cases they are also used for transaction authentication, although this is rather entity authentication for a single-transaction session. In many systems fixed passwords are used for entity authentication and combined with one of the mechanisms explained in the following sections, used for transaction authentication. Moreover, a password is almost always required to bootstrap the system the first time the user starts using it. This is typically different from the password(s) used in the normal sessions.
Passwords should never be sent in clear over the network. They are, however, also vulnerable to dictionary attacks, password guessing, and social engineering. Although these risks have been known for a long time [23], fixed passwords are still widely used, for they are very easy to implement and use.
Banks sometimes issue a list of one-time passwords to their users (at least two banks in our survey). These can only be used once, and should therefore offer more security. However, it is very difficult to learn these by heart, and so the users will be forced to keep a list somewhere either on paper, or worse, on a file on their PC. Terminology banks use includes ‘scratch list number’, mostly used for entity authentication, and ‘transaction number’, used to authenticate individual transactions. Some systems use a combination of fixed and dynamic passwords: fixed for entity authentication and dynamic for transaction authentication. Instead of issuing a list of independent passwords, it is possible to generate a chain of dependent one-time passwords; see for example the system described by Haller et al. in [13] which is based on an idea described by Leslie Lamport in [19]. This usually requires extra software at the client side.
The idea of a challenge/response scheme is that the client proves his identity to the bank (i.e., entity authentication) by demonstrating knowledge of a secret, not by just sending this secret to the bank, but by producing the proper response to a random challenge using this secret. There are symmetric and asymmetric challenge/response schemes. In a symmetric scheme for example, the response consists of a MAC on the time or on a random challenge of the bank. A digital signature on a random challenge message is an example of an asymmetric scheme. These challenge/response schemes are often implemented with hardware tokens.
Using a digital signature for a challenge/response scheme is actually an option in the SSL/TLS/WTLS protocols. When setting up a secure channel between the client and the bank, the client can also be authenticated explicitly using a digital signature: during the handshake, the client signs a hash of all the previously exchanged handshake messages. Usually, the private signing key is stored on the user’s computer and is only protected with a password (see 4.2.5). Note that due to constraints in current WAP phones, this is not yet practically used in WAP banking systems in Iran.
Besides entity authentication, digital signatures can also be used for transaction authentication. This is the most secure alternative. However, of today’s browsers, only Netscape includes a JavaScript mechanism to digitally sign, for example, the contents of a form. So, electronic banking systems normally use their own implementation, a standalone application or an applet, for digital signatures (one bank out of seven in our survey).
As indicated before, the private signing key is usually stored on the user’s computer and is only protected with a password. Moreover, Shamir and van Someren [27] have shown that cryptographic keys are very vulnerable in software. This has been successfully verified by Janssens et al. in [16]. Still, the level of security is substantially higher than when using fixed passwords.
Several of the previously discussed mechanisms can be (more securely) implemented using hardware tokens (one bank out of 10 in this survey).
Private digital signature keys for transaction authentication can be kept on smart cards. Due to the cost of issuing extra smart cards to users, this highly secure solution is not frequently deployed in Iran. However, existing smart card applications can be and are used as a means for entity authentication, e.g., electronic purses, or an electronic identity card.
Note that one can never achieve perfect security, but only (substantially) increase the cost required for a successful attack. As such, more advanced attacks on smart cards remain possible, as shown by Anderson and Kuhn in [1] and Kocher et al. in [17].
Hardware tokens which display a response to the current time interval (e.g., SecurID [26]) or to an unpredictable challenge given by the bank via the computer screen and typed in by the user on the token (e.g., Digipass [5]), are used for entity authentication. These hardware tokens can sometimes also calculate MACs for the purpose of transaction authentication.
Mobile devices such as PDAs or special-purpose wireless wallets can enhance an Internet or WAP banking system’s security. These devices are considered personal, and can perform cryptographic protocols, to provide both entity and transaction authentication. The communication between the device and the PC or WAP phone is realized manually, with Bluetooth [15] or with an infrared interface.
The compromise of one token could lead to the disastrous scenario in which the bank should issue a new token to all users. To prevent this, all tokens should contain a different cryptographic key. When using asymmetric keys this is not a problem. However, in the case of symmetric keys, it requires the maintenance of a secure database containing all the secret keys the bank shares with its users. Symmetric keys are therefore often cryptographically derived from a unique serial number of the token and a master key that is the same for all (or a subset of all) the tokens. In this way, each user shares a different key with the bank, without the problem of the secure database.
Communications security, i.e., a secure channel between a client and an authenticated bank, and client authentication, i.e., entity and transaction authentication, are the two main security issues present in an electronic banking system [7]. There are, however, some additional security issues, which unfortunately in practice are sometimes the most critical ones.
Before a user can actually use a secure Iranian electronic banking system, a registration procedure is performed. During this registration procedure, the security of the system is bootstrapped: the user has to obtain an initial means for entity authentication, with which a first secure session can be established with the bank; thereafter, the regular security authenticators are enabled. Usually an initial password is used which the user obtained via paper mail, and/or after having physically authenticated in one of the bank’s offices. Sometimes, user authentication via the phone is required at the first login at the Iranian bank’s system; the user then for example has to give the operator a challenge displayed on screen, and/or answer some questions. It is clear that if something goes wrong during this stage, the security of the rest of the electronic banking system is undermined.
In some situations, the ability of delegation within an electronic banking system is desired. For example, the manager of a department in Iran would like to be able to delegate (restricted) rights to one or more employees who need to have access to the company’s banking transactions, or possibly parents would like to delegate certain rights to their children.
If the authentication of the client is only based on a fixed password, delegation can unfortunately be performed by just sharing the password. However, this is not delegation but rather impersonation. If client authentication is more secure, it is more difficult to give away the necessary secret information, or at least, it is difficult to duplicate it, for example in the case of smart cards.
A small number of existing electronic banking systems in Iran and other countries worldwide implement some kind of real delegation mechanism. For example, the owner of a bank account can create additional password-protected accounts with limited rights.
When discussing the establishment of a secure communications channel between a client and the authenticated bank, and the authentication of the client, the assumption has to be made that the user’s PC, operating system, and software form a secure end-point in this process. Unfortunately, this is mostly not true in reality in Iran. Critical trusted anchors (see earlier) are thus not always present. Typical client platforms have shown to be very vulnerable, as described by Loscocco et al. [20]. Viruses, Trojan horses, worms, and other malicious programs can tamper with the installed root certificates, they can steal a user’s private keys, they can spoof the user interface or mislead users in another way, they can intercept communication before it is ‘securely’ sent to the bankTP PT, etc.
Even smart cards may not protect against this problem. If the card is unlocked by typing a PIN code via the ordinary keyboard, the PIN code could be captured or the user could be requested for the PIN code through a fake interface. Ideally, a smart card reader should therefore have its own pinpad and a small display. Users do not have to enter PIN codes via their computer’s keyboard then. Users are then also able to verify crucial information on a trusted display, i.e., not their regular computer screen. Common specifications for such secure readers are being developed [8]. However, it still constitutes an expensive solution. Most current smart card readers therefore only consist of a slot in which the card can be inserted. This still protects the card’s private key itself, but does in theory not prevent access to the card’s signing function.
An industry alliance has been working on mechanisms that provide more trust and enable security on an end-user’s computing platform [30]. This effort in particular enables a more secure creation of digital signatures on an end-user’s computing platform [29].
Also the bank’s server should form a secure end-point in the Iranian electronic banking system. The appropriate measures should be taken to prevent hackers from breaking into the site. A discussion of these measures falls out of the scope of this article, but detailed information can be found in Garfinkel and Spafford [12].
The fact that a client platform is not secure is often just due to the lack of security knowledge of the end-user. Although the typical client platform is inherently insecure, most problems could be prevented by an educated, careful, and security-conscious user. Iranian users should keep their security authenticators, whether these are just passwords, a list of one-time passwords, hardware tokens, or the PINs to unlock these tokens, private, and protect them from potential abuse. Users should install virus scanners, and keep them and their system up-to-date. Users should avoid practices that easily lead to security hazards; in particular they should not start up arbitrary executable attachments received via electronic email. Users should check fingerprints of certificates against the fingerprints that are (should be) given by the bank on official paper documents. Iranian Banks should provide information to their users about these matters. In fact, they mostly do this to be able to decline responsibility in case something goes wrong and it turns out it is due to the user. The bank’s system administrators should be properly trained in computer security. They should for example regularly monitor security advisories and apply software patches when required.
The previous sections made clear that there is no such thing as perfect security. No matter the amount and strength of security measures in place, there will always be remaining potential security weaknesses. As some security breaches cannot be completely prevented (e.g., obtaining and misusing a user’s credentials), logging and monitoring will allow the Iranian bank to at least detect security hazards, or find out later what exactly happened. These detection mechanisms can go from just passive logging to active monitoring, e.g., sending an alert to the bank if certain transactions do not match a user’s regular profile.
As technology evolves, more of daily life’s activities are moved online in Iran. Electronic banking is an important example of this trend. The issues discussed in this paper are generally applicable to ecommerce, e-government, and other e-services in Iran and any other country throughout the globe. A first main security issue consists of the establishment of a secure channel to provide data confidentiality and data integrity of communications between a client and an authenticated Iranian bank. The second security issue is the authentication of the client, at the beginning of a session, i.e., entity authentication, and for each transaction, i.e., transaction authentication.
With respect to the first issue, almost all today’s Iranian electronic banking systems rely on the SSL/TLS/WTLS protocols. Although similar solutions would be possible, this is certainly the most popular alternative, as it is available in all common Web browsers. From a cryptographic point of view, SSL/TLS/WTLS has proven to be a practically secure protocol. With respect to the second issue, fixed passwords are still most widely used in Iran, as they are easy to implement and use. From a security point of view, public-key cryptography is the best solution, and the only one providing non-repudiation.
However, the client’s private key is in practice often stored in software and only protected by a password. Smart cards (and readers) constitute a solution that still seems to be too expensive or complicated for Iranian. The best current practice in Iran — i.e., with proper balance between security and cost — therefore is probably the use of other hardware tokens, such as a Digipass, that generate responses to unpredictable challenges of the bank and that are able to calculate MACs, or tokens such as a smart card that is already used in other (related) applications, as in, for example, an electronic purse.
Even the best solution relies on the assumption that the end-points of the system are trusted. Concerning the client, this means that the Iranian electronic banking system should run within a trusted environment that has not been tampered with. This is, however, far from trivial in a typical client environment. The Iranian user must be responsible for maintaining his computing environment, and keeping it trustworthy. The user must also protect the secret elements that are used in the system, such as passwords, private keys, or tokens. While inherently more secure environments will considerably improve the overall security of an Iranian electronic banking system, education of users has an even more significant impact on its overall security. Banks in their turn should ensure the security of their servers.
Security is all about risks and associated costs. In a typical Iranian electronic banking system, the cost of security measures at the client side is reduced as much as possible, while keeping a minimal level of protection. One cannot achieve perfect security, so at some moment in time, despite all security measures something will always go wrong. The real question is what will happen in that case. Iranian banks of course will want to pass liability to their users and vice versa. Law and small print on contracts will somehow make clear who will have to take the risk in the end.
Copyright © 2024 Research and Reviews, All Rights Reserved