Security in MultiCash - UniCredit Bank Srbija ad Beograd

International Banking
Omikron Systemhaus
GmbH & Co. KG
Von-Hünefeld-Str. 55
D-50829 Köln
Tel.: +49 (0)221 -59 56 99 -0
Fax: +49 (0)221 -59 56 99 -7
omikron@omikron.de
www.omikron.de
Security in MultiCash
Overview of relevant features
Version 1.02 / Dez. 2006

Security in MultiCash
CONTENT :
1 BACKGROUND......................................................................................... 3
1.1 Security aspects of MultiCash................................................................ 3
1.2 Overall Security and External Audits ..................................................... 3
2 LOCAL SECURITY.................................................................................... 5
2.1 Access Control and Access Rights........................................................ 5
2.1.1 Passwords........................................................................................................... 5
2.1.2 Users / User Groups............................................................................................ 7
2.1.2.1 Functional Profiles ............................................................................................... 7
2.1.2.2 Data Profiles........................................................................................................ 7
2.1.3 Dual Control......................................................................................................... 7
2.2 Approvals ................................................................................................. 7
2.3 Logs and Audit Trail ................................................................................ 7
2.3.1 System Log ......................................................................................................... 7
2.3.2 Additional Logs .................................................................................................... 8
2.3.3 Payment History .................................................................................................. 8
2.4 Confidential Payments ............................................................................ 8
3 EXTERNAL SECURITY............................................................................. 9
3.1 NTFS Security .......................................................................................... 9
4 SECURE COMMUNICATION WITH MCFT............................................. 10
4.1 Background............................................................................................ 10
4.2 MCFT – How it works............................................................................. 10
4.3 Compression.......................................................................................... 11
4.4 Confidentiality........................................................................................ 11
4.5 Electronic Signature.............................................................................. 12
4.6 Initialization ............................................................................................ 12
4.7 Note on the use of TCP/IP communication.......................................... 12
5 ADDITIONAL SECURITY ASPECTS FOR MULTICASH@WEB............ 13
© 12/2006 Omikron Systemhaus GmbH & Co. KG 2

Security in MultiCash
1 Background
1.1 Security aspects of MultiCash
This document provides an overview of the security mechanisms in MultiCash. The
following areas have been identified by users as most security sensitive and are subject of
the document :
• Local Security : Security functions within the MultiCash application
• External Security : Interaction with the operating system
• Secure Communication : Security features of the standard
communication protocol MCFT
Omikron recommends users of an Electronic Banking application to take these aspects into
consideration and to implement what is necessary to meet the requirements of the
particular installation in line with audit considerations.
The document aims to cover all security-sensitive areas of MultiCash. The main
enhancements realized in version 3.20 are specially highlighted (see shadowed boxes).
1.2 Overall Security and External Audits
In the case of most banks who provide MultiCash to their clients there has been an internal
certification – of both the products and the related processes – made by their internal audit
department.
As software supplier, we can make the following general statements on this question :
The approach to certification in the complex area of Electronic Banking software can be
divided into several areas, which must be considered in quite different ways :
A. Communication procedures
This is certainly the most important area, since here security-relevant data are transferred
over public networks. For communication between the bank and its clients, a number of
different procedures are being used, which are as a rule defined by the banks in the
context of the markets in which they are active. Typically, the "Owner" of the procedure in
each case has organized a certification of this procedure. The results of these audits and
certifications are not available to us, as software supplier.
As background information, here is a list of the most common communication procedures
used :
1. MCFT : This procedure is based on the standard protocol "EPFT" (ZVDFUE), built to the
specifications of the German banking community. This procedure is widespread within
Electronic Banking implementation across Europe, since it is included as standard process
within the MultiCash application. Omikron has continued to develop this procedure over the
years, and in the course of this process taken over the "Ownership". Therefore we as
Omikron commissioned an external security audit from the company "debis IT Security
Services". A description of the MCFT protocol is included under Chapter 4 below ; a
summary of the findings of the debis audit can be provided on request.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 3

Security in MultiCash
2. BCS-FTAM : Currently, this is the valid standard communication procedure of the
German banks for corporate business. According to our information, an audit was
commissioned by the German Central Credit Committee, when the procedure was first
implemented. If this is relevant for you, please request your bank to provide information on
this audit.
3. BCS-FTP : This procedure is the further development of the BCS standard on the basis
of the FTP transport protocol. It was defined by the German private banks, who can
provide further details on request.
4. HBCI : This is the currently valid standard communication procedure of German bank for
private clients and small businesses. According to our information, an audit was
commissioned by the German Central Credit Committee, when the procedure was first
implemented. If this is relevant for you, please request your bank to provide information on
this audit.
B. Application
Following the development of the software and our internal quality control, each new
program version is delivered to the individual banks and the organizations defined for the
task of acceptance by the Bank Associations. These parties then subject the software to an
extensive acceptance process. Only when all checks have been made in the areas of
• User-friendliness
• Software quality
• System security
• Correct processing
is a release approved for delivery to bank clients.
In Germany, the following organizations are responsible in this area :
1. For private banks : Bank-Verlag GmbH, Köln
2. For cooperative banks : BIK Betriebswirtschaftliches Institut der
Kreditgenossenschaften, Frankfurt
C. Enbedding with the end-user
It is not possible to certify an application generally in this area, since the security
requirements depend primarily on how the application is embedded in the environment of
that user, and what specific requirements that user has.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 4

Security in MultiCash
2 Local Security
2.1 Access Control and Access Rights
2.1.1 Passwords
Logon to the system is by means of user-ID and password. After first log-on, the user is
prompted to change his password. After three false attempts this user is blocked and has
no further access to the application until released by an authorized administrator. The
passwords are always stored in encrypted form, as follows :
• The User Login password is stored in the user database, encrypted with DES
• The Administration password is encrypted with DES in several parameter files
In addition, it is possible to set :
• Minimum length of password
• Validity period, after which password must be changed
In addition, a password history can also be maintained, and a period set, during which
passwords may not be re-used.
For each individual user, it is possible to define time windows within which access to the
application is permitted / denied. In the same way, usage can be restricted to defined days.
Version 3.2 : Alternative Logon-Procedures
a) Use of Windows passwords
As an alternative to the logon using User-ID and password, the Windows User-ID can be
stored in the MultiCash user administration. At logon, this User-ID will be reconciled with
that one of the current Windows user and, if applicable, an automatic logon will be
executed with the corresponding MultiCash User-ID. The entry of ID and password is then
not necessary, nor is the regular prompt to change the password within MultiCash.
b) Logon with RSA Signature
If an increased security is required instead of the simplified logon described above, the
“Logon with ES“ can be activated. In this case, the logon is made by an Electronic
Signature, for which the ES medium must be inserted. This same signature is used for
authorization of transactions to the bank(s).
Version 3.2 : Additional password rules (optional)
A. Additional password options in the system parameters (the options can be combined):
1. Inactive users block after x days
Intended to reduce the risk that user accounts which have not been used for a longer
period of time are used for attacks.
2. Minimum number of letters
3. Minimum number of figures
4. Minimum number of special characters
5. Max. number of characters in ascending sequence
© 12/2006 Omikron Systemhaus GmbH & Co. KG 5

Security in MultiCash
6. Password change only once per day
If this option is activated, a password change can be executed only once per day. This
should prevented a user immediately returning to his old password after the enforced
password change.
7. Enforce password change
So far, it has been possible to cancel of the prompt for password change after a
password has expired, in order that the change cycles can be easier synchronized with
other applications. If this new option is activated, the user will be forced to change his
password when his existing one has expired.
8. Not more than 2 same characters in sequence
9. Check negative list (stored in INI file)
If this parameter is activated, new passwords are checked against the negative list
stored in a defined control file and are rejected if they match.
10. Display last access for logon
As a control against program abuse, the display of the time of the last access can be
activated using this option.
11. For ES logon with hardware ES, no password prompts any longer
If this parameter is activated, no signature password will be prompted when signing as
long as the logon to the chipcard is still valid (i. e. the card has not been removed from
the reader since logon).
B. In addition, the following fields are added to the user record:
1. Last access time
2. Use Windows users
This allows the time of the last access to be controlled by the system administrator for each
user.
C. The following additional functionalities have been implemented:
1. For password change: Check password rules according to A.
2. For logon: Display date and time of the last access (if A.10 is activated)
3. For logon: if applicable, prompt Windows users and when they agree, logon without
password prompt (if the corresponding option is set in the user record)
4. For logon: if applicable ES logon (if the corresponding option is set in the user record)
5. In the first automat run of the day, check the last logon time of all users and block users
if period is exceeded according to A.1.
6. In the Users dialog: After manual change of the fields “Password“ or “Blocked“, prompt
for password change at the next logon of the relevant user.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 6

Security in MultiCash
2.1.2 Users / User Groups
Users may be assigned to User Groups which are defined in advance by authorized
adminstrators. For users and/or user groups, access rights can be defined as follows :
2.1.2.1 Functional Profiles
Access can be permitted / denied for users and/or user groups down to the level of
individual functions. This allows a strict segregation of organisational functions between
users, in line with internal audit requirements.
2.1.2.2 Data Profiles
The use of data profiles ensures that any user has access only to data for which he is
authorized. In addition, it is possible to define whether access to certain data is available to
a defined user as read-only.
2.1.3 Dual Control
Access to sensitive administration functions, in particular additions and changes to users
and access rights, is subject to the password authorization by an administrator, or
optionally two administrators (dual control).
2.2 Approvals
In most implementations, one or more payment modules are included within an installation
of MultiCash. All payment modules within the product range offer a matching approvals
mechanism, which allows payment orders to be protected against unauthorized changes,
and to ensure that only complete and pre-authorized payments are sent to the banks. The
approvals mechanism includes :
• Single approval, applicable to a single payment order
• Multiple approval, allowing several orders for a pre-defined account to be viewed
and selected / excluded for approval
In addition, it is possible to define different approvals levels by order type, and to set an
amount (in base currency) from which a second approval is mandatory.
2.3 Logs and Audit Trail
2.3.1 System Log
A system log can be activated : this log records all menu options which are called during
sessions with the application, including time and name of the user
© 12/2006 Omikron Systemhaus GmbH & Co. KG 7

Security in MultiCash
2.3.2 Additional Logs
Further information which may be required in specific cases is included in additional logs,
including a log for capture of all communications sessions with results.
Changes in version 3.20
Log entries have been stored so far separately according to the type in different text files.
The relevant entries for
> Error log
> Communications
> System log
> MT940 processing log
> Plan data reconciliation log
are now combined to be stored in a central file. The display is made in a central overview,
in which the data can be easily selected, printed or output to PDF.
2.3.3 Payment History
A full history of all orders and payment files is kept, including full details of payment files
including
• Status
• Time of all activities made (e.g. creation of file, signatures), with names of users
involved
• Answer code from communication and timestamp from the bank
This allows tracking of individual files/orders at a later date.
2.4 Confidential Payments
New feature in version 3.20
MultiCash is increasingly used as central solution within the corporate network and is used
by all divisions of the company. This means that payment orders originated in different
parts of the company, with varying responsibilities are stored in one place. Often, these
orders also differ in terms of confidentiality (e. g. credit transfers to suppliers, wages and
salaries, customer direct debits). Given this situation, a concept was developed which
allows access to confidential payments – throughout the entire system - only to persons
explicitly authorized for this. In the realization, the following detailed requirements were
taken into consideration:
1. The access protection is effective within all payment modules (on the basis of individual)
transactions and in the File Manager
2. All payment formats used in MultiCash are supported, even if no unique ID for
confidential payments is included in the files or defined in the format itself
3. The rules are defined centrally in the user administration.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 8

Security in MultiCash
3 External Security
3.1 NTFS Security
MultiCash can be operated together with NTFS-Security. In this mode, the access to
resources (directories etc.) is not permitted to the user who is logged on, but to a system
user for the application MultiCash, who receives his own account at operating system level
for this purpose.
Note : this is implemented from version MCC 3.01 for WinNT / Windows 2000
© 12/2006 Omikron Systemhaus GmbH & Co. KG 9

Security in MultiCash
4 Secure Communication with MCFT
4.1 Background
The MultiCash application supports a number of different communication options, based on
standards of different countries and banks. In the following we refer only to the secure
communication protocol “MCFT“, which is provided by default in the application and is the
most widely used option internationally.
MCFT is a dialog-oriented protocol for the transfer of data. This includes the transfer of
files from a corporate to the banks (e.g. payment files) as well as the collection of data from
the banks (e.g. balance and transaction data). With MCFT, communication is possible via
the communication protocols TCP/IP, X.25, ISDN and Modem-Modem. This
communication protocol is supported by banks in over 20 European countries and has
been audited and approved by various international auditors, with a particular focus on the
use of MCFT over the internet.
4.2 MCFT – How it works
All data transferred between Bank and Customer are fully encrypted. A key component of
the encryption is the exchange of Public Keys, using the algorithm of Diffie / Hellmann,
after each successful transmission, so that each tranmsmission is secured with a new key.
This guarantees that this information is not to be used for decrypting a future message,
even in the theoretical case that a used session-key becomes known. Since an additional
„Timestamp“ is generated for the sending and receipt of the message, it is also impossible
to use a cumbersome decryption procedure to manipulate the message.
On the Bank side, an automated process controls Customer access. Each customer is set
up with a set of permissions for bank services, as identified by validated session types.
Before the original file (e.g. a payments file) is transferred, a start block is sent, which
includes .a series of significant details, i.e. a customer ID, user ID, accounts to be debited,
electronic signatures and check sums over the entire file.
During communication (online, during the transmission of start blocks), the following
checks are then made :
• Authorization of the user (validation against immediately previous communication
session)
• Authorization for a specified bank service (e.g. international payments,
documentary credits etc.), defined by session type
• Authorization for access to the specified account
• Provision of sufficient signatures
• Limit checks (limits set up for this Electronic Delivery channel)
If one of these checks fails during transmission of the start blocks, the transmission is
immediately aborted by the bank server. The customer receives a clear message in the
form of an answer code, which is held in a log file on both customer and bank side. This
check is made on the Communication Level. This ensures that customers of the bank can
in no case access directly the maintenance functions, database server or file server, even
where this is installed within a Local Area Network (LAN).
© 12/2006 Omikron Systemhaus GmbH & Co. KG 10

Security in MultiCash
The communications server can therefore be viewed as a “Blocking Firewall“ within the
Back Office environment. As a result, any abuse or error can be detected early, in which
case the communication process is aborted immediately. The file is then rejected.
• A trailer, or end block is always transmitted at the end of the dialog, whether it is
successful or has been aborted. Response codes in the trailer allow the result of
the communications session to be accurately identified.
• If the Electronic Signature is not correct, the communication session will be
aborted before transmission of the original file. If the electronic signature is
accepted, the file will be transmitted. The bank system then needs only to
calculate the „fingerprint“ and match this against the one received in the start
block, which has already been verified. If the electronic signature is correct, the
result of the various checks are transmitted at the end of the communication; these
are then displayed on the customer system, and logged accordingly in an audit
trail.
The general flow of customer – bank communication with MCFT is outlined in graphic form
below :
Private
Key A
Private
Key B
Customer Bank
Original file
RSA
CHK2
CHK6
EUZ
ES file
4.3 Compression
RSA
DAD
MCDFUE dialog
Start block
Answer block
Data
Final mess.
Acknowl.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 11
Checks:
����
����
����
����
Session type
User
Account
ES
Check
CHK2
CHK6
EUZ = ES Intermediate File
CHK2 = Checksum 2
CHK6 = Checksum 6
RSA = Rivest, Shamir, Adleman encryption method
Data compression is achieved on the basis of the internationally accepted and highly
efficient algorithm which is integrated in PKZIP software for data compression.
4.4 Confidentiality
The data are protected against unauthorized viewing during transmission by the use of
Triple-DES encryption. A key exchange according to Diffie-Hellman is made : the new keys
are calculated on the customer and the bank side after each successful communication,
but are never sent across the line themselves.
EU file
Original
file

Security in MultiCash
4.5 Electronic Signature
The MCFT protocol supports optionally the use of Electronic Signature (also known as
digital signature). The signatures are sent automatically in a single session with the
instruction file. A check is made on the access rights of the party sending, the validity of the
Electronic Signature are made in one step during the communication dialog, so that both
security and user-friendliness are guaranteed. Key features of the Electronic Signature as
used within MCFT are :
• Use of RIPEMD-160 for building the hash
• Use of RSA 1024bit for generating the Electronic Signature
• The keys can be stored on disk or ChipCard. In case of diskette, the Private-Key is
stored in encrypted form (Triple-DES – more details, see below). In case of
ChipCard, special secure storage facility of processor chipcards is used.
4.6 Initialization
• The private details for Electronic Signature S are currently encrypted using Triple-
DES 192 Bit CBC. Using PKCS#5, a 24 Byte key and an 8 Byte initialization vector
are generated from the user's password. In the PKCS#5 key generation, two
random values are included which are stored in the public part of the file. The first of
these is an IterationCount, which outlines how often the generation function is
executed internally, and the second of these is a so-called Salt, which represents a
starting value for generating the keys. From these three components (password, salt
and IterationCount) the PKCS#5 algorithm generates the required keys.
The customer sends the Public Key to the server at his bank(s). In parallel he prints an
“Initialization letter“ (or INI letter), which is sent by mail (or fax) to the bank. The bank
checks the personal signature on the INI letter against their documents and checks that the
signature in the letter matches that sent electronically. The user’s Public Key is then
released by the bank.
4.7 Note on the use of TCP/IP communication
Independent of the application MultiCash, it is important to ensure sufficient protection
against the dangers within the use of the TCP/IP protocol over the internet by the
appropriate measures in the infrastructure (firewalls etc.) This always applies when PCs
within a company are connected to the internet.
At the same time, we stress that within the protocol MCFT, the security mechanisms are
implemented up to the application layer. For this reason the transport of data between
corporate and bank is secured.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 12

Security in MultiCash
5 Additional Security aspects for MultiCash@Web
MultiCash@Web is the optional add-on for the MultiCash customer application, providing a
browser interface for (some or all) individual users of the application.
When MultiCash@Web is used beyond the company Intranet, SSL-encryption can and
should be used for the communication between the browser clients and the MultiCash
installation.
With MultiCash@Web, the client has no access rights to the resources (directories etc.) of
the MultiCash Server.
In any case, the access to resources can be controlled using NTFS security on the
MultiCash server.
When using MultiCash@Web, there is no need for active components (e.g. Java applets.)
to be installed. It is only necessary to install a plug-in for Electronic signature, if this
function is being used. This means that the browser settings for the user can remain at a
very high level of security.
© 12/2006 Omikron Systemhaus GmbH & Co. KG 13