In this section: |
Encryption makes information unintelligible to anyone but the intended recipient and decryption renders it intelligible again. iWay Adapters employ standard cryptographic algorithms for encryption and decryption operations.
The server uses standard algorithms that are the basis of public key encryption implementations. Also called asymmetric encryption, these implementations require key pairs, one of which is public and one of which is private. Individuals or corporations typically use this function when they need to authenticate themselves electronically or sign or encrypt data. They publish the public keys, and they keep the corresponding private keys secret. If you use this feature, the data you encrypt with your public key can only be decrypted with your private key.
To send encrypted data, you encrypt the data with the public key of the recipient and the recipient decrypts it with their corresponding private key.
Public key encryption imposes considerable computational overhead and is not always appropriate for securely transmitting large amounts of data. It is more feasible to use public key encryption to send a symmetric key, which you can use to encrypt additional data. This is the approach used by the SSL protocol. Once you initiate a secure dialogue successfully, you can trust simpler symmetric key encryption for the rest of your correspondence.
While encryption and decryption address eavesdropping, they provide no protection from tampering and impersonation, the roll of digital signatures. Tampering detection and authentication techniques rely on a mathematical function called a one-way hash.
When two hashes match, it shows the data is unchanged since it was signed. If they do not match, the data may either have been tampered with after signing, or the signature may have been created with the wrong private key. When hashes match, you can be certain that the public key used to decrypt the digital signature corresponds to the private key used to create the digital signature. Truly confirming that identity, however, also requires confirming that the public key really belongs to a particular person or other entity.
To create a personal certificate, you create a public-private digital key pair and send a certificate request to a certificate authority. The certificate authority will return a certificate binding your identity to your public key. Do not release your private key to anyone, since you sign documents with it. Should you fail to protect your private key, others could potentially sign documents in your name without your consent. You can then give your public key to anyone who needs to verify your signature.
Encryption strength is gauged by how difficult it is to uncover the key. The difficulty of uncovering the key given a quantity of encrypted test depends on the length of the key and the algorithms employed in generating the encrypted text from the plain text. Encryption strength is described in terms of the key length expressed in bits. The 128-bit keys that iWay employs with the RC4 symmetric-key cipher, supported by SSL, provides significantly better cryptographic protection than 40-bit keys. The 128-bit encryption is roughly 3 x 1026 times stronger than 40-bit RC4 encryption.
Certificates identify individuals or entities and authentication confirms those identities. Certificates are electronic documents that associate an identity with a public key. Like passports, licenses, or other personal IDs, certificates provide generally recognized proof of identity. Public key cryptography employs certificates to avoid impersonation.
Certificates work much the same as other forms of identification. Certificate Authorities (CAs) validate identities and issue the certificates. Before issuing a certificate, the CA uses its published verification procedures for that type of certificate to ensure that the entity requesting a certificate is who it claims to be. The certificate issued binds a particular public key to the name the certificate identifies (such as the name of an employee or a server). Certificates help prevent impersonation through use of fake public keys. Only the public key certified by the certificate works with the corresponding private key held by the entity identified by the certificate.
In addition to a public key, certificates always include the name of the entity, an expiration date, the name of the authority that issued the certificate, a serial number, and other information. Most importantly, a certificate always includes the digital signature of the issuing CA, which allows it to function as a letter of introduction for users who know and trust the CA but do not know the party identified by their certificate.
For e-commerce, authentication means making confident identification of a potential business partner by another, whether they be two people, or two entities, such as a client, which might be browser software running on a personal computer, and a server, such as the software and hardware hosting a Web site. Client authentication refers to the identification of a client by a server (that is, identification of the person using the client software). Server authentication refers to identification of a server by a client (that is, identification of the organization responsible for the server at a particular network address).
Client and server authentication are not the only forms of authentication that certificates support. For example, the digital signature on an e-mail message, combined with the certificate identifying the sender, provides strong evidence that the person identified by that certificate sent that message. Similarly, a digital signature on an HTML form, combined with a certificate identifying the signer, proves after the fact that the person identified by that certificate approved the contents of the form. In addition to authentication, digital signatures ensure a degree of non-repudiation, making it difficult for signers to later disclaim sending the messages. Consider two forms of client authentication:
Consider a scenario where a user requests a resource controlled by a server. In response to an authentication request from the server, the client requests the user name and password for that server. The user must then supply a name and password separately for each new server they wish to use in a session. The client sends the name and password across the network and the server looks up the name and password in its local password database and, if they match, accepts them as evidence of the user identity. The server determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.
To authenticate a user, a client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network. The server authenticates the user identity from this evidence. Certificate-based authentication is generally preferable to password-based authentication because it is based on what the user has (a private key) as well as what the user knows (the password that protects the private key). These assumptions will fail if unauthorized personnel have access to the user machine or password. Public key cryptography can only verify that a private key used to sign some data corresponds to the public key in a certificate. Users must protect the physical security of their machines and keep their private key passwords secret.
| iWay Software |