Introducing Security Components

In this section:

The foundation of iWay Service Manager security structure is public key cryptography and its related standards and techniques. This framework allows users to:

Transmission Control Protocol/Internet Protocol (TCP/IP) is the accepted method for sending information across the Internet. However, its flexibility, which led to its worldwide acceptance, provides potential for security breaches such as eavesdropping, tampering with information in transit, spoofing transmissions from other users, and impersonating or misrepresenting others in transactions.

It is imperative that you take every available action to protect your communication from these threats. A principal technique employed to secure Internet commerce is public key cryptography, which facilitates the following security operations:

The following topics introduce the public key cryptography concepts that iWay products employ to facilitate these capabilities.


Top of page

x
Key-Based Transaction and Message Encryption

Encryption makes information unintelligible to anyone but the intended recipient and decryption renders it intelligible again. iWay employs mathematical cryptographic algorithms for encryption and decryption operations. To further augment the security of the encrypted results, iWay applies unique numeric keys to these algorithms. iWay supports public key encryption.

RSA Data Security algorithms 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, 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 recipient's public key 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.

Private key encryption also enables you to sign data with your digital signature, which is another important requirement for electronic commerce. Your recipient, using client software, can then use your public key to confirm that you signed the message with your private key and that it was not tampered with after you signed it.


Top of page

x
Key Length Adds Strength

Encryption strength is gauged by how difficult it is to uncover the key. The key depends on the cipher algorithm and key length, both of which rely on the difficulty of factoring large numbers. 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.


Top of page

x
Digital Signatures

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 a certificate authority. Do not release your private key to anyone. 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.

Public Keys. Public key certificates create proof of a signer's identity through the services of a certificate authority. Certificate authorities use a variety of processes to associate a particular public key with an individual. You can then give your public key to anyone who needs to verify your signature. Your public key and proof of identity are combined in a public key certificate that is also called a signer's certificate.

Private Keys. Private keys are known only to you. You sign documents with your private key. The public and private keys are related mathematically, but it is not possible to deduce the private key from the public key. Through your public key, recipients can verify your signature, but it does not allow them to create new signatures. Should you fail to protect your private key, others could potentially sign documents in your name without your consent, so it is essential to keep your private key confidential.

Digital Certificate. Digital certificates are digital documents issued by a certification authority containing a holder's name, serial number, public key, and the document's expiration date. Digital certificates are used in a public key infrastructure to send and receive secure, encrypted messages.

Digital Signature. A digital signature is an electronic signature that employs a public key infrastructure to verify who sent (and/or) signed a document. Digital signatures are comparable to handwritten signatures. Having signed data, it is difficult to refute having done so later, assuming your private key was not compromised or out of your control. Digital signatures thus prevent repudiation and are as legally binding as handwritten signatures in certain situations.


Top of page

x
Trusted Parties, Certificates, and Authentication

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 the use of falsified 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.


Top of page

x
Client Authentication

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 website. 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 email 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's 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's identity. The server determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.


Top of page

x
Certificate-Based Authentication

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's 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, however, if unauthorized personnel have access to the user's 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 their machines' physical security and keep their private key passwords secret.


Top of page

x
Keystores

iWay Service Manager maintains a database of private keys that correspond to public keys published in any certificates issued for it. Clients request the password to this database the first time they need to access it during a session. For example, the first time a user attempts to access an SSL-enabled server that requires certificate-based client authentication. After entering this password once, a user need not reenter it in that session, even to access other SSL-enabled servers. The client unlocks the private key database, retrieves the private key for the user's certificate, and uses that private key to digitally sign data randomly generated for this purpose on the basis of input from the client and the server. This data and the digital signature constitute evidence of the private key's validity. The digital signature can be created only with that private key and can only be validated with the corresponding public key against the signed data, which is unique to the SSL session.

The client sends both the user's certificate and the evidence (the randomly generated piece of data that was digitally signed) across the network. The server uses the certificate and the evidence to authenticate the user's identity. At this point the server may optionally perform other authentication tasks, such as checking that the certificate presented by the client is stored in the user's entry in an LDAP directory.

The server then continues to evaluate the identified user's access permission for the requested resource. This evaluation process can employ a variety of standard authorization mechanisms, potentially using additional information in an LDAP directory, company databases, and so on. On determining a positive evaluation, the server enables the client to access the requested resource.

As certificates replace the authentication portion of the client/server interaction, instead of requiring users to send passwords across the network throughout the day, a single sign-on enables users to enter the private key database password just once, without sending it across the network. For the remainder of the session, the client presents the user's certificate to authenticate the user to each new server it encounters. Existing authorization mechanisms based on user identity authentication are not affected.

The five types of certificates commonly used with iWay products are:


Top of page

x
Secure Sockets Layer (SSL) Protocol

The SSL protocol specification defines a set of rules governing server authentication, client authentication, and encrypted communication between servers and clients. Widely used on the Internet for interactions involving exchanges of confidential information such as credit card numbers, SSL requires at least a server SSL certificate. As part of the initial handshake, the server presents its certificate to the client to authenticate its identity. The authentication process uses public-key encryption and digital signatures to confirm that the server is the server it claims to be. You may also configure servers to require client authentication as well as server authentication. In this case, after server authentication is completed, the client must also present its certificate to the server to authenticate the client's identity before the encrypted SSL session can be established.


Top of page

x
Secure Multi-Purpose Internet Mail Extension (S/MIME)

Many email programs support digitally signed and encrypted email using the widely accepted S/MIME protocol. Its use to sign or encrypt email messages requires that the sender of the message have an S/MIME certificate. Email messages that include digital signatures provide reasonable assurance that they were sent by the person whose name appeared in the header, thus authenticating the sender.



x
Using CA-Based Certificates to Establish Trust

Certificate authorities (CAs) are entities that validate identities and issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server. Certificate Authority Services provides a list of third-party certificate authorities. Any client or server software that supports certificates maintains a collection of trusted CA certificates.



x
Ensuring Data Integrity With Message Identification Code

Data integrity is ensured using a Message Identification Code (MIC). MICs are computed hash values that are created based on the content of the AS2 message, and using the sender's private key.

This private key is then used to sign the document. Recipients of the message can check the integrity of the message by recomputing the MIC value of the AS2 message (using the sender's public key) and comparing the value with the MIC provided in the digital signature.


iWay Software