FEATURE

Framework for Evaluating Security Protocols in a Banking Environment

J. H. P. Eloff and Suzi van Buuren

T his paper presents an evaluation framework for security protocols that can be used to secure

a b a n k ' s s y s t em. The f r a m e w o r k f irs t ly distinguishes between different bank applications, such as securing electronic transactions, securing message exchanges between remote parties, and s e c u r i n g the b a n k ' s sys tem resources . Fur the rmore , the framework evaluates the security services and the level of the services provided by a protocol. It also evaluates the architectural layer on which the services are provided.

Introduction Online banking has become unavoidable if banks are to survive in the future. The Internet is being looked at as a new channel to extend existing services, offer new services and enter new markets; not merely for marketing purposes, but also as a means to generate revenue through electronic commerce.

Unfortunately, connectivity to the Interact also opens a window into the bank's local network through which the entire Intemet community can peer. A vital banking issue to address is, therefore, information security, especially in the light of the fact that information is deemed to be one of a bank's biggest assets.

There are several solutions available to provide security services such as authentication, confidentiality, and integrity, to a bank's information. Most of the solutions currently available rely on some security protocol to provide the security services. The security protocols then depend on security mechanisms such as passwords, encipherment , or digital s ignatures to provide protection for information. These security mechanisms in turn then depend on security algorithms such as SHA, RSA or DES.

For instance, in order to provide the confidentiality service to an application or a user, a security protocol

Users and applications Clients, merchants, payment applications, file transfer applications, mail applications.

Security services Authentication, access control, confidentiality, integrity, non-repudiation.

Security protocols SET, SSL, PCT, SHTTP, PPTP, PGP, etc.

Security mechanisms PIN, password, secret key, ACL, encipherment, hashing, MAC, digital signatures, certification.

Security algorithms Policy, DES, RSA, MD5, SHA, random.

Secret information Password/Key lengths, password/Key storage.

Figure I: Security dependencies.

Computer Fraud & Security January 1998 © 1998 Elsevier Science Ltd

15

FEATURE

such as Pretty Good Privacy (PGP) can be used, which uses cryptography as a security mechanism. This security mechanism will depend on the strength of a security algorithm, such as DES, which will, in turn, depend on the strength of a key and the storage of that key. The longer the key, the higher the level of confidentiality that will be provided. These security dependencies are indicated in Figure 1.

Security framework

There exist several security protocols that can be used to provide security for a bank's system. Some of these protocols are:

Intern~t Keyed Payment Protocols (iKP) from IBM which implements encrypted credit card-based transactions.

PayWord and MicroMint , two simple micropayment schemes from R.L. Rivest and A. Shamir.

Secure Courier by Netscape. A cardpayment scheme based on public-key technology built on the Secure Sockets Layer protocol.

Secure Electronic Transactions (SET) draft standard for credit card payments, proposed by MasterCard and VISA which supersedes the earlier proposals STT (by VISA, Microsof t ) and SEPP (by MasterCard, CyberCash, GTE, IBM and Netscape). SET achieves secure, cost-effect ive, online transactions that satisfy market demand and are the

Step 1

Step 2:

Step 3:

Step 4:

Network architecture

Security classes

l Security services

I Security layers

Figure 2: Framework for securing a banking environment

single, open industry specification for electronic transactions.

The problem is to decide which protocol will provide the best security for a bank in a specific application.

Figure 2 indicates a general security framework that can be used to distinguish between different security protocols that should be used in different bank environments. It can also be used to evaluate the security functionality of the protocol for the specific application where it is useful.

Step 1: Determine the network architecture for which the system was developed

Figure 2 states that a security protocol should be evaluated firstly according to the specific network architecture for which it was developed.

With client/server applications, part of the code runs on the client and part on the server. The client side interacts with users, while the server side works with stored data and resources attached to servers. A request-and-response conversat ion is carried on between the client and server on a continuous basis.

The reason for this specific network architecture is that it lends itself to easy Interact connections that will provide banks with extended online banking opportunities. A banking system should make provision for connectivity to the Internet to ensure maximum flexibility and business benefits. The key to success with this endeavour is the ability to provide clients and business partners~with access to existing commercial applications.

Step 2: Determine the security class of a protocol

Step 2 indicates that a protocol being evaluated for a banking environment can be divided into various security classes. This classification can be one of :the following as a combination of the classes defined by IBM and Microsoft.

Secure electronic transactions, for securing communications in electronic transactions between a client and a merchant. These security protocols, mainly include security features to secure a

16 Computer Fraud & Security January 1998 © 1998 Elsevier Science Ltd

FEATURE

bankcard number, as well as the amount and goods agreed upon, in a purchase from a merchant . Protocols that can be used in this class are, for instance, Secure Electronic Transactions (SET), Secure Transactions Technology (STF) and Secure Electronic Payment Protocol (SEPP).

Secure-message exchange, for secur ing communications between remote consultants and a bank or between remote clients and a bank. This class of secure banking will include secure communication between distributed client/server parties over an open system, such as the Internet. Remote clients can make use of a security protocol in this class to securely require statement information, do payments, do interaccount transfers, as well as obtaining other information such as interest rates. Remote consultants can make use of a security protocol in this class to secure messages containing applications for home loans, client information, or approvals of home loans. The Secure Sockets Layer (SSL), Private Communications Technology (PCT) and the Secure Hypertext Transfer Protocol (SHTYP) are some examples of protocols that can be used to secure this security class.

Secure-system resources, for securing the bank's resources in a private network. This class can include securing communications in an intranet between various bank branches. This class does not involve any secur ing communica t ions on the Internet, it only secures communication on the intranet; files, databases, and application software on servers, mainframes and workstations in the banks private network. Distributed branches can make use of a security protocol in this class to transfer files, and mail messages in a distributed intranet. Examples of protocols that can be used to secure this class is Poin t - to-Poin t Tunnel ing Protocol (PPTP), Kerberos and SESAME.

Step 3: Determine the security services provided by a protocol

Step 3 indicates that a protocol being evaluated in each class will have to provide certain security services, in order to ensure the security in that class. A security protocol can be used mainly to provide one main security service, or more than one.

For instance in the secure message exchange class, a remote client will need to authenticate himself to a branch, ensure the integrity of the message contents, and ensure that the information that he sent to the branch is kept confidential. Furthermore, a bank must be able to prove that a client did a transfer, for instance, so that the client cannot deny an action that took place.

The securi ty services required in the secure message exchange class are, therefore: authentication, integri ty , conf iden t ia l i ty , and non- repud ia t ion . Protocols can be combined to provide all the required information security services.

To further distinguish between different protocols that provide the same security services in the same class, the levels of security services can be used to evaluate which protocol provides the highest level of a security service.

For instance, the levels of non-repudiation are indicated below, with the h ighest level of non- repudiation at the top.

T Certification Digital signature MAC

In order to provide proof of both the sender and the r ece ive r ' s or ig in of a message , any of the above -men t ioned m echan i sm s can be used. Send i ng a c l ea r - t ex t a c k n o w l e d g m e n t cou ld const i tu te p roof that the sender has received a packet, but since the latter message could well be forged, it does not p rov ide an adequate level of non- repudiation. By using a digital signature or a MAC, the origin of a m es sage f u r n i s h e s proof that the sender was the person who sent the message, since the MAC and the digital signature are computed by using the secret key of the sender. The digital signature provides a higher

"a bank must be able to prove that a client did a transfer, for instance, so that the client cannot deny an action that took place"

Computer Fraud & Security January 1998 © 1998 Elsevier Science Ltd 17

FEATURE

level of secur i ty , s ince it is c o m p u t e d us ing a symmet r i ca l c ryp tography , while a MAC only includes a secret key in its generat ion. The use of c e r t i f i c a t e s f u r n i s h e s even be t t e r p roo f of origin, since a certificate is generated by a trusted third party, who verifies that a person is who he or she claims to be.

The minimum level of security service required is speci f ic to the ind iv idua l appl ica t ion . For example, transaction security services associated with electronic data interchange are quite different from those services used for inquiries about interest rates. In an electronic-transaction message, non-repudiation is very important to ensure that a client cannot deny that a transaction has taken place, and then demand a refund for the transaction from the bank. On the other hand, if a remote client were to make an inquiry on the bank's current interest rates, a denial by the client of having done so will have no financial impact on either the bank or the client.

Suggested minimum requirements for the security services in all three classes are as follows:

Secure electronic transaction class

• authentication by means of a secret key

• con f iden t i a l i t y by means of symmet r i ca l cryptography (DES)

• integrity by means of a hash function

• non-repudiation by means of a digital signature

Secure-message exchange class

• authentication by means of a password

• con f iden t i a l i t y by means of symmet r i ca l cryptography (DES)

• integrity by means of a hash function

• non-repudiation by means of a MAC

Secure-system resources class

authentication by means of a password access control by means of mandatory access control mechanisms, such as access control lists

• con f iden t i a l i t y by means of s y m m e t r i c a l cryptography (DES)

• integrity by means of a hash function

Step 4: Determine the security layer at which the protocol provides security services

Step 4 of Figure 2, indicates that the services of a protocol can be at d i f fe ren t layers , such as the application layer or the network layer.

Application layer security usually resides either in the application itself or in the transport layer of the ISO/OSI r e f e r e n c e mode l and the TCP/ IP architectures. These security mechanisms will handle all security within the protocol and will not trust lower layers, such as the network layers, to effect any key management or storage.

Network layer security resides in the lower layers of the OSI and TCP/IP architectures. It does not depend on reliable transport mechanisms. Network layer security is independent of the applications at the application layer.

Security services provided on the network layer differ from services provided on the application layer. Confidential i ty on the application layer can, for instance, be applied only to certain messages that contain sensitive information, and not to all the messages in communicat ion between two parties. Confidentiality on the network layer, however, will be applied to the entire communication session, since at a lower layer you cannot make a dis t inct ion between sensitive and non-sensitive information. The d is t inc t ion of services on d i f f e ren t layers can prov ide a bank wi th g u i d e l i n e s to dec ide which protocols can be used in combination with. each other.

18 Computer Fraud & Security January 1998 © 1998 Elsevier Science Lid

FEATURE

Evaluating the SET protocol according to the security framework

Step I: Determine the network architecture that the system was developed for Secure Electronic Transaction (SET) protocol is a method to secure bankcard transactions over open networks, such as the Interact. These specifications are available to be applied to any bank card payment system.

The SET protocol can, therefore, be used in an open distributed client/server environment, suitable for a banking environment.

Step 2: Determine the security class of a protocol

SET provides secure payments for distributed clients and merchants, via the Internet. It is, therefore, a protocol for the secure electronic transaction class in the framework.

Step 3: Determine the security services provided by a protocol

SET provides authentication for the client, merchant and the acquirer payment gateway. The receiver of a message can authenticate the sender by verifying the received data. The sender can authenticate himself to the receiver, as well as to any third party. Both of these au then t i ca t ions are a ccompl i shed using digi tal signatures and public key certificates issued by a certification authority (CA). The authentication is, therefore, on the level of a secret key.

In order to insure conf ident ia l i ty , SET uses symmetr ical encryption, as well as asymmetr ical encryption. DES is used in SET to protect sensitive financial data (payment instructions). In addition, symmet r i c a lgor i thms are expec ted to separate confidentiality of payment data from confidentiality of non-payment data, and are required on merchant-to- acqui re r in te r faces and on the cus tomer - to -CA interface. SET uses 56-bit DES encryption.

SET provides integrity by means of hashing as well as digital signatures. The Secure Hash Algorithm (SHA-1) 160 bit, is used for hashing. Signatures in

SET will employ the RSA signature algorithm with SHA-1 hashing.

SET provides non-repudiation by means of digital signatures as well as certificates. One of the parties in communication can, therefore, not deny sending a message, since a trusted third party authenticated him in the message.

Step 4: Determine the security layer at which the protocol provides security services

The SET protocol provides services at the application layer, since it does not trust any lower layers to perform a part of the services and the services are also data sensitive.

Conclusion

The framework proposed in this study successfully provides a bank with a guideline not only to evaluate p ro toco l s , but also to dec ide which p ro toco l s can be used in c o m b i n a t i o n wi th each other . Furthermore, security protocols should be used in combinat ion with each other. Securi ty protocols should be seen as building blocks to achieve a secure bank system.

One security protocol can secure more than one class in the framework. Security protocols should thus be used in coordination with each other, to secure a bank sys tem as a whole . All the c lasses in the framework must thus be utilized in coordination with each other, to secure a banking environment as a whole.

Secur i ty p ro toco l s should also be used in combination in one class; to ensure that all the specific security services required be provided on the minimum required level. Two security protocols can thus be used to secure one class.

Protocols on different layers can also be used in combination to provide security on more than one architectural layer. Protocols that provide services on the network layer can be combined with protocols that provide services on the application layer.

Computer Fraud & Security January 1998 © 1998 Elsevier Science Ltd 19