Home banking computer interface
Homebanking Computer Interface ( HBCI ) is an open standard for electronic banking and customer self-service. It was developed by various banking groups in Germany and decided by the Central Credit Committee (ZKA; today Die Deutsche Kreditwirtschaft ). HBCI is a standardized interface for home banking. Transmission protocols, message formats and security procedures are defined.
technical features
Outstanding characteristics of HBCI are the bank independence, the provider independence and the public availability of the standard. This means that in principle every programmer or software manufacturer can create an implementation of the HBCI client side and thus access all HBCI-capable banks. The standard provides several authentication options. A large number of providers now provide the necessary software modules.
HBCI can work with PIN and TAN (now iTAN) implemented in software without additional hardware. Cryptographic keys are then z. B. stored in files. A data connection is established from the computer to the bank when entering the data. Depending on the HBCI version, this connection uses either its own HBCI protocol on TCP port 3000 or the usual HTTPS protocol for websites .
HBCI with a chip card offers a higher security standard . The key is generated by the chip card itself and stored exclusively on it. So that this cannot be compromised, the key cannot be read from the outside. The entire cryptographic encryption therefore takes place on the chip card and is carried out by its processor . The methods used here are the symmetrical DES -DES method (DDV) and the partially asymmetrical RSA -DES hybrid method (RDH). The HBCI chip cards are called DDV cards and RDH cards and differentiated according to the method.
Development history
HBCI was first published in a practical form in 1998 as version 2.01; Designs go back to 1995. This was followed by versions 2.1 (1999) and 2.2 (2000), which differed relatively little from one another except for additional business transactions.
In the time between HBCI 2.2 and HBCI 3.0, the German Savings Banks Association had used a version called HBCI + , in which a PIN / TAN security procedure was used.
In 2002 the HBCI version 3.0 was published, in which the PIN / TAN procedure from HBCI + was included as an alternative security solution in the HBCI standard, and signature cards were added. Apart from that, the structures from the previous versions continued to apply in a similar form. HBCI 3.0 has been renamed FinTS 3.0 (Financial Transaction Services).
Finally, in 2004, the FinTS 4.0 version was introduced. In this version, all internal data structures have been converted to XML and XML schemes , HTTPS has been used as the communication protocol and other new interfaces (e.g. WWW portals) have been introduced.
After an initially hesitant introduction, HBCI has been offered by approx. 2000 banks in Germany since 2002, i.e. around half of all German banks. Although the standard was originally intended to be used internationally, HBCI remained limited to the German banking market.
Improvements in security through the use of chip card readers
Home banking with an HBCI chip card and a chip card reader that supports PIN entry (security class 2 or higher) offers a higher level of security. HBCI with chip card and card reader according to the Secoder standard are currently regarded as the ultimate in security, whereby the respective bank and home banking software must support the Secoder extension for HBCI. Successful attacks on this configuration are unknown. The following theoretical attack scenarios only apply to card readers that do not conform to the Secoder standard:
Theoretically, a malicious program could manipulate the home banking program used, so that instead of the displayed and issued order, it would secretly sign a changed order and send it to the bank's server, i.e. not initially understandable for the user. The bank will execute the order if it has been correctly signed. However, such a case has not yet become known - for good reason: because of the spreading effect, attackers usually use security holes in operating systems or frequently used programs such as browsers. For the aforementioned attack scenario, the malicious program would have to be tailored specifically to a particular home banking program. Since home banking is used much less frequently than online banking and various programs are in competition, the considerable effort due to the small target group would be in an unfavorable relationship to the “benefit” - which makes such attacks extremely difficult and therefore unlikely.
The card reader is not involved in the encryption of the actual transfer, but only encrypts the transfer signature generated by the home banking program. This is still a weakness of the system. Just like most home banking methods, home banking via HBCI and card reader is only secure under the assumption that the home banking program used on the PC could not be manipulated by attackers.
However, with the chip card procedure, neither the cryptographic key of the card can be read out, nor is it possible to eavesdrop on the PIN entry with a keylogger or Trojan horse. Phishing is therefore not entirely impossible with this method, although one must be in possession of the electronic signature in order to successfully carry out a transaction. H. must have the chip card in principle.
Methods with TAN generators offer an alternative to the HBCI chip card procedure .
Vulnerabilities
In September 2001, on behalf of the ARD program Ratgeber Technik , hackers succeeded for the first time in manipulating an HBCI server of the Munich Hypovereinsbank with the help of Trojans so that the transfer orders sent according to the HBCI standard at the time could be intercepted and decrypted with all the necessary information . Although the HBCI version from 2001 was soon considered obsolete, hackers on behalf of the HR show Trends succeeded again in May 2005 in cracking an HBCI server, now owned by Dresdner Bank . The background to this attack was that the chip card could be copied and used by unauthorized third parties.
With today's HBCI standard, transactions are no longer legitimized with a TAN. Rather, the bank customer signs a checksum of his transaction data with his secret key stored on the card and sends this data to the bank. Since the signature process takes place in the card (from which the secret key cannot be read), an attacker cannot simulate an authorized transaction on the bank's server.
Another security hurdle is that the bank customer also has to enter his PIN in order to activate the process.
Components of the standard
HBCI essentially specifies two large sub-areas of online banking: On the one hand, several security procedures are defined for the authentication and encryption of orders, for example chip cards or PIN / TAN. On the other hand, data formats and processes for the execution of individual banking transactions are specified with business transactions, for example individual transfer , sales retrieval of an account , change of a standing order, etc.
Security procedures
RSA key disk
HBCI supports floppy disks or other data carriers as a security medium for a self- generated RSA key pair. The transactions are protected against unauthorized changes by a digital signature .
At the time of the first HBCI publication, a floppy disk was still the predominant writable removable medium, so that the "key disk" is often used (alternatively: "key medium"), so any other storage medium (e.g. USB stick or RSA Chip card) can be used just as well.
An RSA key pair with a key length of 768 bits is generated for authentication in the customer's software (HBCI2.x; from FinTS3.0 also 1024 to 2048 bits, called "security class RDH-2/3/4"). After that, an electronic fingerprint (is user fingerprint ) of the public signature key printed on paper and signed sent to the bank. At the same time, the public RSA key is sent electronically to the bank's HBCI server. The bank can use the signed fingerprint to ensure that the electronically submitted key actually and exclusively comes from the signing bank customer. This means that the self-generated key is securely authenticated and can now be used to sign every order.
A 2Key Triple DES procedure is used for message encryption . A new 112-bit one-time key is generated for each message, which is then encrypted with the permanent RSA or DES key. This mixing of the RSA and DES processes is referred to in the HBCI standard as the RSA-DES hybrid process (RDH).
The storage format of the RSA key on the data carrier is not specified in the HBCI standard. The data format and protection of the security medium via PIN is determined by each software manufacturer, which often means that self-generated keys of HBCI software cannot be used by competing HBCI programs.
DES chip card
A chip card is authenticated implicitly in that the chip card is presented to the bank customer. The DES chip card contains triple DES keys with a length of 112 bits.
As with the RDH method just described, the data to be transmitted is encrypted using the 2Key Triple DES method, which uses two DES keys with 56 bits each for encryption. The communication data are first encrypted with the first key, then the decryption algorithm is applied to the intermediate result with the second key and this intermediate result is encrypted with the first key. The decryption of the data on the recipient side takes place according to the same principle in reverse order. The entire DES key is 112 bits long. By using two keys of this length in the manner described, the security of the data is not doubled but increased to the power.
RSA chip card
With an RSA chip card, the same processes result as with a key disk, except that the RSA key generated is generated by the processor on the RSA chip card and the private key never leaves the chip card. This makes this method particularly secure, but RSA chip cards are still quite expensive.
PIN / TAN
HBCI 2.2 was expanded (initially unofficially) to include the PIN / TAN procedure. One spoke here of HBCI 2.2 PIN / TAN or HBCI +. From version FinTS 3.0, HBCI orders can also be officially authenticated with the PIN / TAN procedure. The variants of the PIN / TAN procedure used in HBCI + and FinTS 3.0 differ from one another.
The data transfer takes place via a secure HTTPS / SSL connection, which is usually permitted by firewalls ( port 443). This represents a certain advantage compared to the previous HBCI, which required the release of port 3000. This procedure uses the advantages of HBCI together with the usual handling of TAN lists, which means a simplification of HBCI access, especially from the banks' point of view.
However, you lose some of the security advantages of HBCI, for example the transactions with PIN / TAN are no longer electronically signed. Another problem is the increased occurrence of phishing for PIN and TAN, i.e. the creeping of PIN and TAN through trickery. Nevertheless, more and more credit institutions are offering this transmission method, especially since previous PIN / TAN accesses used the outdated access via T-Online Classic (BTX), the operation of which was only maintained for banking applications and was associated with correspondingly rising costs.
Business transactions
The HBCI server of a bank reports by means of bank parameter data (BPD) which business transactions this bank in general and by means of user parameter data (UPD) which it allows for a user in particular.
List of HBCI business transactions
Available and supported bank parameters according to ZKA and server feedback from the respective bank.
| Identifier | Surname | Spk Ha 450 500 01 | Postbank Do 440 100 46 |
|---|---|---|---|
| DKPAE | Change PIN online | x | x |
| HIISA | Transmission of a public key | - | - |
| HIKIM | Credit institution report | - | - |
| HIPRO | Report status log | - | - |
| HIPROS | Status protocol parameters | - | - |
| HISYN | Sync response | - | - |
| HKAOM | EU - Transfer | x | x |
| HKAUB | International transfer | - | - |
| HKCAN | Account turnover / new turnover (camt) | - | - |
| HKCAZ | Request account transactions in the camt format / period | - | - |
| HKCCS | SEPA payment | x | x |
| HKDAB | Get standing order stock | x | x |
| HKDAE | Set up standing order | x | x |
| HKDAL | Delete standing order | x | x |
| HKDAN | Change standing order | x | x |
| HKECA | Account statement (camt) | - | - |
| HKEKA | Pick up account statement | x | x |
| HKEND | End of dialogue | - | - |
| HKFPO | Fixed price order (proprietary trading) | - | - |
| HKIDN | ID | - | - |
| HKISA | Public key request | - | - |
| HKKAN | Get new account transactions | - | - |
| HKKAU | Get an overview of account statements | - | x |
| HKKAZ | Get account transactions | x | x |
| HKKDM | Customer message | x | - |
| HKLAS | Direct debit | - | - |
| HKLSW | Direct debit contradiction | x | - |
| HKNEZ | Subscribe to a new issue (new issues) | - | - |
| HKOAN | Request order display | - | - |
| HKPPD | Phone card recharge | x | - |
| HKPRO | Get status log | - | x |
| HKQTG | Send receipt | - | - |
| HKSAL | Get the balance | x | x |
| HKSLA | Collective debit | - | - |
| HKSLB | Scheduled collective debit inventory | - | x |
| HKSLE | Submit scheduled collective debit | - | x |
| HKSLL | Delete scheduled collective debit | - | x |
| HKSPA | Request SEPA account details | x | x |
| HKSSP | Key lock | - | - |
| HKSTP | Euro STP transfer | - | - |
| HKSUB | Collective transfer | x | x |
| HKSYN | Sync message | - | - |
| HKTAB | Display TAN media inventory | x | x |
| HKTAU | Register / re-register TAN generator | x | - |
| HKTAZ | Show TAN list | x | - |
| HKTML | Deactivate / delete TAN medium | - | - |
| HKTSB | Scheduled collective transfer inventory | x | x |
| HKTSE | Submit a scheduled collective transfer | x | x |
| HKTSL | Delete scheduled collective transfer | x | x |
| HKTUA | Change appointment transfer | x | - |
| HKTUB | Get hold of schedule transfers | x | x |
| HKTUE | Set up appointment transfer | x | x |
| HKTUL | Delete appointment transfer | x | x |
| HKUEB | Single transfer | x | x |
| HKUMB | Rebooking | - | - |
| HKVVB | Processing preparation | - | - |
| HKWFO | Fund order (fund) | - | - |
| HKWPD | Bring a list of securities accounts | - | - |
| HKWPK | Security price query | - | - |
| HKWPO | Security order (stocks, bonds, warrants) | - | - |
| HKWPR | Get security reference numbers | - | - |
| HKWPS | Order cancellation | - | - |
| HKWSD | Request securities master data | - | - |
| HKWSO | Request order status | - | - |
FinTS - the further development of HBCI
FinTS stands for " Fin ancial T ransaction S ervices" and contains safety procedures with electronic signature (chip card or self-generated RSA key disk) and in contrast, the security procedures PIN / TAN. FinTS sees itself as a modular system (legitimation procedures, business transactions and financial data formats are separated from the protocol).
FinTS 3.0 - expansion of the possible security procedures
FinTS 3.0 is characterized in particular by the introduction of the signature card as a uniform security medium. With this signature card, a legally binding declaration can be made in electronic business transactions. In addition, the security procedures have been adapted to the current state of the art - for example, the key length has been increased. The previous PIN / TAN extension was included in FinTS 3.0 as an alternative security procedure to HBCI.
With the introduction of FinTS 3.0, the designation “HBCI” is used for a certain group of security procedures in which the chip cards and RSA key files are referred to as “HBCI security procedures” and are differentiated from the PIN / TAN security procedures. In the previous versions, however, the designation "HBCI" stood for the entirety of business transactions together with all known security procedures. In this respect, it would be entirely appropriate to speak of a renaming from HBCI to FinTS .
FinTS 4.0 - the change to XML syntax
With FinTS 4.0, the underlying message syntax of the protocol was changed to XML. In addition, the options for communication between the home banking client and the banking system have been made more flexible. This created the possibility of asynchronous communication (via SMTP). The banking system can now also become active on its own and send the home banking customer information previously subscribed to by the latter (for example his account turnover) in a cycle specified by the customer.
See also
literature
- Ulrich Schulte am Hülse, Sebastian Klabunde: The tapping of bank access data in online banking - the approach of the perpetrators and new civil law liability issues of the BGB. In: Multimedia and Law (MMR). Volume 13, No. 2, 2010, ISSN 1434-596X , pp. 84-90.
Web links
Individual evidence
- ↑ HBCI Home Banking Computer Interface - Interface Specification - VIII.6.2 TCP / IP
- ↑ ZKA HBCI / FinTS version comparison ( Memento of the original from January 27, 2012 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. (PDF; 27 kB)
- ↑ ZKA specification FinTS 3.0 alternative ZKA security procedures (PDF; 1.2 MB)
- ↑ Insecure online banking: ARD lets bank computer "hacked" ( memento of the original from February 14, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved February 14, 2016.
