Digital signature in the Electra Client Program

printable version

Banks must be able to provide evidence of the following for a long period:

  • authenticity: orders were actually received from the customer identified as the sender and were not entered into the system by some unauthorised party;
  • integrity: the content of a specific order has not changed over time, and the bank executed exactly what it was requested in the order;
  • non-repudation: so that a customer could not say later that he did not want the order to be executed or did not want it to be executed with the given content.

Digital signatures are needed in the Electra system to comply with the above requirements. Although the procedures stored in the system are encrypted and only those with appropriate privileges can access the data, it is still important to note that encryption is basically not part of digital signature functions.

Digital signatures protect customers' as well as banks' interests. Digital signatures are made by one or more users on the client side and are always verified by the Electra server upon submitting a signed order (or order package). Regardless of the channel used for the transfer, any order submitted via Electra must have an authenticated digital signature to be forwarded to the bank's systems.

The Electra system allows each user to select from the following digital signature generation tools and methods (depending, of course, on the bank's offer, requirements and agreement made with the customer): they may use one-time codes (TAN codes), signature passwords, chip cards, SMS authentication or a combination thereof.

One-time passwords are so called TAN codes, which are generated random numbers associated with the user by the Electra server and printed on paper. The user may choose any of the codes printed on the paper as his digital signature but each code can be used only once. Following the verification and acceptance of the signature, the given TAN code becomes 'used' and cannot be used to authenticate any further order. Using a TAN code printed on a different sheet of paper will cancel the validity of any unused TAN code printed on previous sheets.

From the user's perspective, using a password signature means the introduction of another password independent from the one used for logging in. Signature passwords are known only to the user, who can change them any time after logging in. Through the use of a so called password policy, the bank can enforce compliance with different requirements when a user changes his password, e.g. it may define a minimum password length or complexity (obligatory use of letters, numbers or punctutation marks), a password expiry period, or not allow using previous passwords.

If using chip cards, each user uses a personal authentication key stored on a card. Nobody can access these signature keys directly: even the rightful user can only get the results of the encryption operations performed by the chip using the keys. When using a chip card for digital signatures, the signature password is replaced with the PIN code necessary for using the card. If selecting this signing method, the user will need a chip card and a so called chip card reader, which is an electronic device that can be connected to a computer.

If the user selects SMS authentication for signing his orders electronically, the Electra server will send one-time passwords to his mobile phone in simple SMS messages. SMS passwords are generated at random at the time of signing the orders and are sent to the user through a communication channel completely independent from the Electra system. Besides, these SMS passwords can only be used for a limited period of time. This method is considered to be one of the most secure methods today. Due to the necessary involvement of the bank's server, SMS authentication can only be used when the user is online (logged in).

The Electra server uses a so called public-key encryption standard, the RSA algorithm for digital signatures. The system currently uses 512- to 2,048-bit keys for signing orders. The private signature and the public decryption RSA keys are defined on the customer's computer, when the application is installed (registered). (If using a chip card, the key will be generated and stored by the card itself, and will not be accessible to anybody.) The client program will send the public part of the RSA key to the Electra server but the private part will remain hidden. The digital signature itself is a code made based on the content of the order using the private signature key. This code would be extremely difficult to be reproduced by a party other than the given user, this is why the bank can declare that the specific order could only be signed by the given user. The Electra server can verify the signature using the public part of the RSA key.

The Electra Client Program stores the private RSA key in an encrypted form not only on the hard disk but also in the memory of the computer. Since the availability of the authentication key is of utmost importance, the client program ensures that there were a number of backup copies of the file storing it.

The system generates a checksum for the complete business content and authenticity-related technical content of the order package using a standard, so called SHA-1 hash generation procedure. The signature code ensuring authenticity is calculated based on the hash and the code generated from the signature password, using the already mentioned RSA algorithm. The hash in the signature guarantees that the business content of the order cannot be modified without detecting the modification.

The Client Program adds the SGML-format codes generated by the cryptographic algorithms and all other information necessary for the digital signature (user ID, Client Program ID, signature date and time, signature score etc.) to the order package.

Any order sent in through the Electra Client Program will only be accepted by the server if the order has digital signatures achieving the appropriate privilege level (i.e. the required minimum total score). So, users adding their digital signatures must have sufficient privileges on the one hand, and their signatures must be authenticated on the other hand. Authenticity is ensured by the digital signature.

When verifying signatures, the Electra server will check if the checksum calculated on the basis of the complete business content and authenticity-related technical content of the order package is the same as the checksum embedded in the package. It will also check if the hash produced by the RSA decryption procedure matches the above checksum and the signature password code stored for the user.

Legal succession between manual and digital signatures

When a new client program is installed, the system will generate initial login passwords for users. These passwords must be forwarded to the relevant customers and their users. Customers must certifiy the reception of the passwords (e.g. in intact and closed envelopes) by their signature. This signature provides legal succession between manual and future digital signatures. The initial password cannot be used for anything else but to log in into the system and to specify a new login and a signature password. This is necessary because the initial password may be known to the employees of the bank. However, the passwords specified by the customer are already received by the bank in a coded form, and from that time on these passwords can be verified but not learnt by other parties.

 
 Related articles