Smart Banking Guide

I just went through several books of banking security. Oh, I have been studying this thing for almost one year. It is not my decision, anyway, not interested at the first place. Anyone who might be interest, give me some ideas about Digital Signatures and Digital Envelopes. Me, I had to hand some assignments about these staff by the end of week.

The following is from “Electronic Banking and Security”, you can either go through this after or directly give me some suggestions.

A digital envelope can be created by the sender encrypting the message. The recipient decrypts the message using a secret key not known to third parties. Thus, the message is secured during its journey through the network. This meets the requirements for an envelope, but implies that we must take measures to provide secure distribution of the secret encryption/decryption keys, a process which we also have to ensure is easily manageable.

A digital signature can be made by the sender by preparing a cryptographic ‘digest’ of the message and attaching this for checking by the recipient. If the digest can be verified against the received message then the integrity is protected. If the cryptographic key used to generate the signature is known only to the signatory, then the requirements for authenticity are also met, but how is a wide community of recipients going to verify the signature, and how will the encryption keys be managed so that non-repudiation and forgery resistance can be implemented?

This is where the selection of a suitable encryption method is of critical importance. The encryption method (or encryption algorithm) is the formula by which the bits of a digital ‘ plaintext’ message are transformed to produce the unintelligible `ciphertext’ version. The use of a secret key controls who may decrypt the ciphertext to recover the plaintext. The algorithm most suited to the EDI application is known as RSA and is named after its inventors Rivest, Shamir and Adleman. It is an asymmetric algorithm in which pairs of keys are used — one key is used to encrypt data whilst the other (related) key is used to decrypt it again. The encryption key is made public, but the decryption key is kept private, known only to its owner. Public keys are made freely available throughout the system by means of a public directory, rather like a telephone directory but in machine-readable form on a computer file.

Consider two members of the community of users, Alice and Bob. If Alice wants to send Bob a private document by EDI, she looks up his public key and encrypts the document under this key. To decrypt the document the matching private key is required and Bob is the only person in the entire world who knows that key. Hence only Bob can decrypt Alice’s document. Here we have our ideal digital envelope — anyone can seal a document in the envelope by using a public key, but only the intended recipient can open that envelope using the corresponding private key.

Now, how about the signature? It turns out that if Alice uses her private key on the document, Bob can recover the plaintext by using her public key. This doesn’t provide privacy because everyone has access to Alice’s public key from the public directory but, since Alice has the private key, encryption of the document using this key provides a unique digital signature, and it can be verified by anyone who can access the public directory, including an official arbitrator. Thus any attempt to repudiate the signature will fail. This meets all our requirements for an ideal digital signature scheme.

System management is easy too. All public keys are readily available on a directory file and only one key, the personal private key of the owner, needs to be stored securely. RSA keys do not need updating because we choose a key length that is for all practical purposes unbreakable. Finally, of course, the private key stays with its owner and never needs to be moved around the network — hence there are none of the complex key management problems associated with symmetric encryption schemes.