Mandate final Report

səhifə	3/6
tarix	26.06.2016
ölçüsü	0.83 Mb.

1 2 3 4 5 6

3. The Mandate Concept

In the following we briefly present the architecture, functionality and design of the Mandate solution, with emphasis on the security, the most critical factor.

3.1 Security Aspects

3.1.1 Replication of paper functionality

The security of a paper cheque is achieved through the cheque being payable to one person, and signed by the issuer. However, since mostly signatures are no longer checked on a regular basis by the bank, the security is mainly achieved by the payee of the cheque being able to identify that he is indeed the person to whom the cheque is in favour. Generally, the payee owns a bank account into which the bank is instructed to pay the cheque. The bank has already, through the procedures it goes through when someone wishes to open an account, assured itself to a satisfactory level that this person is who he says he is. There are agencies which will cash cheques, but these also will insist on identification in order to be reasonably assured that the person receiving the funds is who he says he is.
However, in the paper based solution, the signature of the issuer is typically not verified, but accepted on its prima face, as there are no automated means for handling this. On the contrary, it is extremely costly and requires at a minimum faxing a copy to the bank of the issuer.
The electronic cheque works in much the same way when everything goes well, the cheque is issued to one specific person and to ensure that only that person can use the cheque, the digital signature used to sign the cheque is encrypted with the public encryption key of the person to whom the cheque is being paid. It is thus completely straightforward to check that a particular digital signature does, in fact, belong to a particular person, using standard PKI structures based on certificates. (See the Section on Key Management below).
But everything has a price.

3.1.2 Prevention of double encashment

In the paper environment, it is reasonably easy (although with advanced copying techniques becoming more difficult) to ascertain what is an original. However, with an electronic cheque it is not quite so easy. Someone receiving an electronic cheque could make say three copies, send it to three different bank accounts and get paid three times, although the issuing bank may well identify what has happened, eventually. However, if we add in the endorsement functionality, someone receiving a cheque could make a copy and use it to pay three suppliers, thus exponentiating the fraud, by the time this has gone through the banking system it may be difficult to trace the fraudster(s). Therefore the system needs to be implemented in such a way as to make this impossible.

3.1.2.1 The Mandate^TM Cheque Book

There are only two possibilities: By on-line verification which is quite demanding, or by the use of tamper resistant hardware, which prevents the owner from making copies of the issuers signature, which represents the value of the check.

The Mandate solution is the latter. Thus each user has a Mandate^TM chequebook, which has two pairs of public keys: A signature pair and an encryption pair. None of the private keys of these pairs will be available outside the Mandate^TM chequebook, except for back-up solutions achieved through key recovery. The chequebook will recognise other authorised keys by means of certificates.

3.1.2.2 The protocols

Transfer/endorsement is achieved is by using the public encryption key of the payee and encrypting the digital signature. The cheque, with a unique identification number, can only be signed or endorsed by the originator once and to only one payee. If an attempt is made to defraud the system, by endorsing the cheque to someone and sending it, then taking a copy of the original cheque as received and attempting to use the ‘receive’ function to accept it again, the system will show a message that the cheque has already been received and refuse to continue.

Should the cheque be sent to, or intercepted by, a person other than the intended payee, this person will not be able to ‘receive’ the cheque, as his encryption key will not decrypt the signature.

3.1.3 Increased security

To add security in the paper world, a cheque may require two signatories, or cheques over a specific amount may require two signatories (effectively ensuring that 2 people have authorised the payment). The equivalent of this can also be achieved in the electronic environment. When using Mandate to write a cheque, each time a cheque is issued there is a prompt to fill in the password, to access the Mandate^TMand the digital signature. Therefore if the system is implemented requiring the input of two passwords from separate parties for the issue of each cheque, then we are ensuring the same level of authorisation as in the paper world.

3.1.4 Public Key Certificates

In order that a user of the Mandate system can be sure that the public key he is using comes from a bone fide Mandate user, there will be a public key certificate which certifies the public key as that of the user. Depending upon how the system is implemented, the certificate may be sent along with the key. An alternative method would be to hold the certificates in a directory service so that the user, or rather his Mandate application, could look up the certificate as and when he wished.

3.2 Key Management and Key recovery

The Trusted Third Party functions were defined as:
Produce Mandate^TM

This entity will have to be trusted by all parties to produce hardware and software that can carry out the functions required of the electronic cheque

Personalise the Mandate^TM

The Mandate^TM needs to be personalised, in the same manner as the conventional chequebook, and this information recorded.

Issue Certificates corresponding to public keys on Mandate^TM’s

Each public key will require a certificate which will link the key to that certificate, this is so that anyone using that public key to encrypt the signature can be certain that this is the key of a bona fide Mandate user.

Directory services

Depending upon how the Mandate system is set up there may be a requirement for directory services with the ability to look up whether a certain certificate is still valid or not.

Key Recovery Procedures

As the Mandate^TMis the only entity which can establish the ownership of a particular cheque, the cheques on the Mandate^TM will be lost if the Mandate^TM breaks down. However, if there is a copy of the Mandate^TMsecret encryption key stored by a TTP and the user has a copy of the cheques that were on the Mandate^TM when it was lost or broke down, then the cheques can be recovered.

However, in the instance of loss or breakdown the Mandate^TMwill have to be replaced and a new Mandate^TM created for the user, which will involve new key pairs and the new public keys will have to be made available.

3.2.1 Produce the Mandate^TM

The software and hardware tokens on which the Mandate^TM is implemented will need to be produced by someone who is trusted by the users of the system. Dependent on the amount of trust that the users wish to place in this entity it may be appropriate for this entity to offer further TTP services such as the creation of key pairs for Mandate users, implemented on the Mandate^TM. The Mandate^TM would then be passed on to the bank where the cheques would be created. If this were the case, this entity could also be used to offer directory and cheque recovery services. However, the bank may prefer to offer some or all of these services by itself.

3.2.2 Issue Public Key Certificates

All Mandate banks and users will need certificates corresponding to the public keys of their Mandate^TM’s which need to be sent at the time the public key is sent. The system for issuing certificates and looking up certificates could be implemented in one of two ways. The essential element is for all users to be able to access a certificate at any time to establish the authenticity of another user.

Central CA Function

The central CA issues and maintains the certificates for both Bank Mandate^TM’s and User Mandate^TM’s
With the central CA any user or bank can look up a certificate of another user.

Public Key Hierarchy

In this scenario the banks’ Mandate^TM’ public keys are certified by a root certification authority. Then each bank certifies the public keys of the Mandate^TM’s it issues to its customers. In order to verify that a user is a bone fide user, when sending his Mandate^TM public key to the initiator of a payment the user will also send his Mandate^TM public key certificate (issued by his bank’s CA) together with the certificate of his bank CA(issued by the root authority).

In order to check that the user is a bona fide Mandate user, the recipient will look up the bank’s root certificate, this will confirm that the bank is bona fide, and there will be an address where the certificate of the Mandate User can be looked up (the directory service of that bank).

This is a more complex scenario which involves the user in more than one transaction.

3.2.3 Directory Services

A centralised or distributed directory service can be used to make the public keys and certificates available to all users of the Mandate system.

3.2.4 Cheque recovery

Should a Mandate^TMget lost or damaged whilst there are cheques on it, these cheques will need to be recovered in order for the owner to get value. As the cheque is received on to the Mandate^TMa back up copy of the cheque is made. When the Mandate^TMis lost the user informs his bank and sends the copy of the cheques to the bank. The bank (or another escrow agent) holds a copy of the user’s secret encryption key which was saved when the Mandate^TMwas created. The bank uses this key to decrypt the signature and, if successful the cheque is then ready to be cleared. The bank will, however, wait until the validity period of the cheque has passed before crediting funds to the user’s account and clearing the cheque since it would be possible for the user to have already endorsed the cheque to someone else and then sent a copy to the bank, pretending that the cheque had been on the lost or damaged Mandate^TM. If, by the end of the period of validity, no other cheque has been presented, the bank can credit the funds.

There may need to be added security for the storage of the secret encryption keys such as being kept under a password that is only known to the user of the key.

3.2.5 Key Management/Key recovery

User

The user will need to have access to the public keys and the public key certificates of those parties to whom he wishes to send Mandate cheques. In the pilot, keys were distributed via e-mail and stored in the Mandate application. They were also accessible on the Mandate Web site maintained by Cryptomathic. Whilst this was manageable in the small user group of the pilot, it may not be a suitable way of managing keys in a full commercial environment, since keys change and people open new accounts etc.

One method of dealing with the management of keys is:

For the recipient of the payment to send an electronic message (invoice) together with his public key to the person issuing the Mandate cheque and for the issuer of the Mandate cheque to use this to encrypt his signature. Since it is generally the person seeking payment that initiates the dialogue this would appear to work in the majority of cases, and would also go some way to automating the data flow which would add further value to the user.

3.2.6 Management of Multiple accounts

If a Mandate^TM user has accounts with more than one bank, with the pilot implementation he would need a separate Mandate^TM for each bank account he held. He would also therefore need to distribute different public keys for the different Mandate^TM’s. He might send over the key for the specific account when he requested payment, but it may also be that at that time he does not know which account he wants to pay the money into. The simplest way of dealing with this situation would be for each user to have just one key by which to receive payment. This could be implemented in one of 2 ways:

The user has one Mandate^TM which is used exclusively for receipt of Mandate cheques and separate Mandate^TM’s for each bank account it holds. Once the cheque has been received and the user knows which account he wishes to pay the cheque into he endorses it to that particular account.
The user has multiple accounts on one Mandate^TM. The user receives a Mandate^TM which can store cheques from different banks. The question here is who issues the initial Mandate^TM is this one of the banks or a separate TTP entity?

Bank

The bank’s public encryption key needs to be available to all its Mandate customers in order for them to be able to send Mandate cheques for payment. The other banks using the Mandate system will also need a copy of this key, together with the public key certificate. If anything happens and the bank needs to change this key the new key will need to be made available to all users, and the other banks.
During the pilot, the Consortium was confirmed of the urgency to provide for recovery solutions: at one of participating banks there was no back up at all the system crashed and we had to reinstall everything, which meant creating new keys for the bank and distributing them to everyone. If it had have been possible to reinstall and re-use the old keys this would have saved a lot of problems.

Possible Infrastructure

In order for the CA to issue a public key certificate, it would need a copy of the public key of the Mandate^TM. It would therefore be logical for this entity to make these keys available to other user’s. This infrastructure would then follow the two scenarios outlined above for the possible CA infrastructure