MobiLink transport-layer security and certificates

Section I: MobiLink transport-layer security and certificates

MobiLink transport-layer security protects the confidentiality and integrity of the synchronization data stream as it passes between MobiLink clients and a MobiLink synchronization server. Furthermore, it allows a client application to verify the identity of a MobiLink synchronization server, hence ensuring that it synchronizes with only trusted MobiLink synchronization servers.

This security is implemented by means of digital certificates. These certificates can be used in a variety of ways, depending on the desired level of security. This paper introduces basic concepts that underlie public-key cryptography and explains how they apply to digital certificates. Examples illustrate several typical arrangements, each of which offers different benefits.

Public key cryptography makes use of mathematical systems that work with pairs of very large associated numbers. These numbers, called keys, have particular properties. One of the keys, called the public key , can be published in a public forum (like a phone book) and can be used to encrypt information to be sent to the owner of the public key. The owner keeps the second key, called the private key , secret.

A message encrypted with the public key can be decrypted only by using the private key. Since the public key is published, anyone can create a message that only the private key owner can read. In addition, anyone who knows the public key can decrypt a message encrypted with the private key. In this way, the owner of the private key can "prove" they know the private key by using it to create a message that can be decrypted using the associated public key.

It is essential that the private key cannot be found easily through knowledge of the public key. The ease at which the private key can be derived from the public key is often associated with the strength of the cryptosystem and the size (in bits) of the public key. Another aspect of the private key is that it must be difficult to guess. The generation of high-quality private keys must incorporate randomness designed to be truly unpredictable. The tools provided with MobiLink gather pseudo-random data from the operating system when generating new private keys. Were this data predictable, it would be easier for an adversary to guess the value of your keys.

A digital certificate is an electronic document that identifies a person or entity and contains a copy of their public key. Each certificate includes a public key so that anyone can communicate securely with the person or entity by encrypting information with this public key. Digital certificates conform to a standardized file format that contains the following information:

1. Identity information, such as the name and address of the certificate owner
2. Public key
3. Expiry date
4. Digital signature, to prevent modification of the certificate

Digital signatures

A digital signature provides a means to detect whether a certificate has been altered. A digital signature is a cryptographic operation created by calculating a value, called a message digest, from the identity information and the public key.

A message digest is a calculated bit-value designed to change if any part of the certificate changes. The algorithm used to calculate the message digest is known to all users of the certificates. The correct value is encrypted with the private key for the certificate. Since all certificate users can calculate the message digest value, detecting alteration is simply a matter of calculating the message digest value and decrypting the value in the certificate using the public key. Differing values indicate that the certificate has been altered.

A certificate constructed in this manner is called a self-signed certificate because the digital signature is constructed with the matching private key. Such a certificate cannot be altered without knowledge of the private key.

A MobiLink synchronization server must be able to identify itself to a client with its own server certificate. Since the client must make sure that the certificate is authentic, the client must either already have a trusted copy of the server's public certificate or the server's certificate must be signed by a certificate trusted by the client. In the latter case, the client must have a reliable copy of the signing public certificate. The available configurations are described in later sections.

Furthermore, the MobiLink synchronization server must have access to the private key for its own certificate in order to decrypt messages sent by clients. The private key is contained in a file accessible to the MobiLink synchronization server.

Figure 1 displays a sample certificate file that a MobiLink synchronization server could use. This particular type of certificate, called a server identity, contains the server's private key.



Figure 1: A sample server certificate


Since other users may have access to the machine running the MobiLink synchronization server, the file containing the private key is protected by a password. This password is intended to maintain the honesty of the people given access to the machine. It does not provide an adequate barrier to an outside attack, as the password is only a few characters in length. To further protect the private key, outsiders should be denied access to the MobiLink synchronization server by a firewall, or by other traditional means.

Instead of being signed directly by the certificate authority, the server's certificate may be the first certificate in a certificate chain. In this case, the client must trust the owners of all certificates and must have a trusted copy of the final certificate in the chain, called the root certificate. Such a certificate file would have a structure similar to that shown above, but could contain a longer list of certificates.

SQL Anywhere Studio includes tools for working with certificates. These are included in the distribution if your license permits it. If so, you can choose to install these security components.

A utility named gencert allows you to generate new certificates. Since certificates are normally written in a machine-readable format, another utility, named readcert , displays the contents of a certificate in human-readable format.

You can make a number of types of certificates with the gencert utility. The easiest type to make is a self-signed (root) certificate, as no other signing certificate is required.



Figure 2: A self-signed certificate


The main advantage of a setup with only one root certificate is simplicity; you need create only one certificate. This setup is often sufficient for simple setups involving only one MobiLink synchronization server. If you operate multiple MobiLink synchronization servers, an enterprise level certificate, discussed later, is often more convenient.

The biggest disadvantage is that a self-signed certificate is easier than other types to forge. This type of attack can be accomplished by creating a counterfeit certificate using a different key pair. Other types of certificates are more secure because they bear more than one digital signature.

To indicate that you want to make a root certificate, start the gencert utility from a command prompt using the -r switch. The utility prompts you to enter the identity information, the certificate password and expiry date, and the names of the new certificate files.

> gencert -r

Sybase Elliptic Curve Certificate Generation Tool

Generating key pair using curve ec163a02 (please wait)...

Country: CA

State/Province: Ontario

Locality: Waterloo

Organization: Sybase, Inc.

Organizational Unit: MEC

Common Name: MobiLink self-signed certificate

Serial Number: 2000.02.29.01

Certificate valid for how many years: 2

Enter password to protect private key: password

Enter file path to save certificate: self.crt

Enter file path to save private key: self.pri

Enter file path to save server identity: serv1.crt


The response to each question should be a string, except for the number of years to the expiry date, which must be an integer.

The utility creates three files, using the names you supply. In this case, the following three files are created.

· self.crt This file contains the new certificate, including the identity information, public key, expiry date, and signature. You can give out copies of this file to people whom you wish to contact you.
· self.pri This file contains the private key that matches the public key encoded in the certificate. The private key is encoded using the password you supplied, providing a modest barrier to others with access to your machine. However, since password encryption is not very secure, you must restrict access to this file to maintain secrecy.
· serv1.crt This file contains the same information as the above two files, combined into one file. It is intended for use with a MobiLink synchronization server. The server sends the public information to identify itself to clients. It requires the private key to decode messages returned by the clients. You must restrict access to this file. It, too, contains a copy of the private key, protected only by the password.

Figure 3: The parts of a server certificate


The server certificate contains the information in the public and private certificate files. You can make a server certificate by concatenating a public certificate and the file containing the private key.

You can use the self-signed certificate for server authentication by following these steps.

2 Tell each client that it is to trust only servers that can decrypt messages encoded using the public key contained within the copy of the supplied public certificate. For Adaptive Server Anywhere clients, you do so using the trusted_certificates security parameter. For example, you can tell an Adaptive Server Anywhere client to trust only the self.crt certificate by including the following parameter in the ADDRESS clause of the SYNCHRONIZATION DEFINITION.

CREATE SYNCHRONIZATION DEFINITION test

SITE 'user001'

ADDRESS'security=certicom_tls{trusted_certificates=self.crt}'

(

TABLE sales_order (id, cust_id, order_date, sales_rep ),

TABLE customer (id, fname, lname, phone)

)


To tell an UltraLite client to trust only the desired certificate, name the trusted certificate using the -r switch when running the UltraLite generator, as follows. Enter the entire command on one line.

> ulgen -c " dsn= UltraLite7.0Sample;uid=dba;pwd=sql "

-r self.crt -j custapi

Sybase Adaptive Server Anywhere UltraLite Code Generator Version 7.0.0

Running UltraLite analyzer

Loading schema information

Loading SQL statements

Analyzing access plans

Generating source code for SQL statements

Generating source code for UltraLite schema

Saving source code into database

Writing source code to output file

dbmlsrv7 -c "dsn= UltraLite7.0Sample;uid=dba;pwd=sql"

-xtcpip{security=certicom_tls{certificate=serv1.crt;

certificate_password=password}}


Note that the clients do not need and should not have either the private key or the password that unlocks it. Clients need only the public certificate.

In contrast, the MobiLink synchronization server requires access to the private key, as well as to the public parts of the certificate. Thus, the server requires access to the server certificate file, which contains both public and private information.

The MobiLink synchronization server must have access to the private key and the password that protects it. For this reason, you must ensure that the MobiLink command line and log file are secure. This is best done using a firewall and otherwise limiting access to the machine running the MobiLink synchronization server.

Section VI: Certificate authorities



One problem with self-signed certificates is that an adversary can create a fake certificate using a different public- and private-key pair. Someone, mistaking the fake certificate for the original, may unknowingly encrypt his or her message using the substitute public key, rather than that owned by the intended recipient. Only the adversary, who knows the substitute private key, could read a message encrypted using the fake certificate.

To guard against such an attack, both the user and the owner of the certificate must agree to trust a third party. This third party, called a signing authority or certificate authority , adds a digital signature to the certificate using his or her private key. Once signed, the document certificate can be altered only with the aid of the third party. To sign a certificate, the certificate authority need not know the private key of the certificate owner.

The certificate authority need not be an external person or organization. If the certificates are to be used only within the company, it may be appropriate for someone at the company to act as the certificate authority.

To create a trustworthy system, a certificate authority must carefully check the identity of a certificate owner before signing a certificate. In particular, they must check that the identity fields in the certificate accurately describe the certificate owner and that the certificate owner owns the matching private key.

Someone wishing to use this certificate to communicate with the certificate owner must have confidence in the following.


1 Before signing the certificate, the certificate authority made certain that the identity information contained in the certificate correctly identified the certificate owner.

2 Each private key is known only to the certificate owner.

3 The user has a reliable copy of the certificate authority's public key.


To satisfy these conditions, not only must the user have confidence in the integrity of the certificate authority, but the user also must have obtained the same public key directly from the certificate authority.

To obtain valid copies of a public key, users of this system typically obtain copies of a self-signed certificate owned by the certificate authority. To foil impostors, the certificate must be obtained by reliable means.

In addition, each client must store the copy of the certificate authority's certificate securely. Should an adversary have access to the user's computer, he or she could replace the certificate authority's certificate with a fake.

Section VII: Certificate chains


When deploying a replication system, a large number of certificates may be required. The responsibility of signing many certificates may place too great a burden on the certificate authority. To lessen their workload, a certificate authority can delegate signing authority to others. To do so, the certificate authority signs a certificate held by the delegate. The delegate then proceeds to sign certificates using the private key that matches the one in this certificate.

A certificate chain is a sequence of certificates such that each certificate is signed by the next. The final certificate, called the root certificate, is owned by a certificate authority. For example, a server certificate can be signed by a delegate. The delegate's certificate can be signed by a certificate authority. The certificate authority's public key is contained in a third certificate. Such a situation comprises a chain of three certificates.



Figure 4: A certificate chain


In fact, a delegate can also have delegates. Thus a chain of certificates can be of any length. However, the final certificate is always a self-signed root certificate, owned by a certificate authority.

To trust a chain, a user must trust each of the following.


1 Before signing each certificate, the certificate authority and all delegates made certain that the identity information contained in the certificate correctly identified the certificate owner.

2 Each private key is known only to the certificate owner.

3 The user has a reliable copy of the certificate authority's public key.


All conditions are extremely important. The chain of certificates is only as strong as its weakest link.


Section VIII: Enterprise root certificates


A deployment of MobiLink that involves multiple servers can be improved by assigning each server a unique certificate also signed by a common root certificate. A certificate authority within the enterprise holds the root certificate.

This arrangement has the following advantages.


· Each MobiLink synchronization server can be given a unique certificate, so that if one site is compromised, the others are not affected.
· Security is enhanced because the private key for the enterprise root certificate need not be stored on the MobiLink synchronization server.
· Clients do not need to keep a copy of each server's public certificate, only a copy of the public root certificate, because you can configure them to trust any certificate signed by the root certificate.

The security of the system can be improved somewhat by obtaining a globally signed certificate, discussed later, from a commercial certificate authority. In practice, however, this arrangement provides adequate security for many applications.

You can program your clients to verify the values of some certificate fields, as discussed later, thus ensuring that they synchronize with particular MobiLink synchronization servers within your organization.



Figure 5: Using an enterprise certificate


This setup provides more flexibility than self-signed server certificates. For example, you can add a new server and give it a new certificate. If the new certificate is signed with the same enterprise root certificate, existing clients will automatically trust it. Were you to give each MobiLink synchronization server a self-signed certificate instead, all clients would require a copy of the new public certificate.


Creating the certificates

The first step in setting up an enterprise-level system is to generate the common self-signed certificate. To generate this root certificate, start gencert with the -r switch.

> gencert -c -r

Sybase Elliptic Curve Certificate Generation Tool

Generating key pair using curve ec163a02 (please wait)...

Country: CA

State/Province: Ontario

Locality: Waterloo

Organization: Sybase, Inc.

Organizational Unit: MEC

Common Name: MobiLink self-signed enterprise root

Serial Number: 2000.02.29.02

Certificate valid for how many years: 2

Enter password to protect private key: password2

Enter file path to save certificate: ent_root.crt

Enter file path to save private key: ent_root.pri


Two files are generated.

· ent_root.crt This file contains the new certificate. This certificate should be published as all clients require a reliable copy.
· ent_root.pri This file contains the private key that matches the public key encoded in the certificate.

These two files can be used to sign additional, new certificates. To generate a signed certificate, start gencert with the -s switch. Enter the name of the signing certificate file, the name of the signing private-key file, and the password for the signing private key.

> gencert -s

Sybase Elliptic Curve Certificate Generation Tool

Generating key pair using curve ec163a02 (please wait)...

Country: CA

State/Province: Ontario

Locality: Waterloo

Organization: Sybase, Inc.

Organizational Unit: MEC

Common Name: MobiLink server identity

Serial Number: 2000.02.29.03

Certificate valid for how many years: 1

Enter file path of signer's certificate: ent_root.crt

Enter file path of signer's private key: ent_root.pri

Enter password for signer's private key: password2

Enter password to protect private key: password3

Enter file path to save server identity: serv1.crt


This time, gencert creates only one file. This file contains the signed certificate and the private key. It is intended for use with a MobiLink synchronization server.

Repeat this last step as many times as necessary to create a signed certificate for each MobiLink synchronization server.


> gencert -s

Sybase Elliptic Curve Certificate Generation Tool

Generating key pair using curve ec163a02 (please wait)...

Country: CA

State/Province: Ontario

Locality: Waterloo

Organization: Sybase, Inc.

Organizational Unit: MEC

Common Name: MobiLink server identity

Serial Number: 2000.02.29.04

Certificate valid for how many years: 1

Enter file path of signer's certificate: ent_root.crt

Enter file path of signer's private key: ent_root.pri

Enter password for signer's private key: password2

Enter password to protect private key: password4

Enter file path to save server identity: serv2.crt


You now have the following files.

· Root certificate, ent_root.crt
· Root private key, ent_root.pri
· Root combined certificate, ent_serv.crt
· Combined certificate for the first MobiLink synchronization server, serv1.crt
· Combined certificate for the second MobiLink synchronization server, serv2.crt

You do not need the combined root certificate because no MobiLink synchronization server uses it directly. Instead, you created a separate certificate for each MobiLink synchronization server.


Using the signed certificates

You can use the signed certificates for server-authentication by following these steps.

1 Supply a copy of the public root certificate to all clients. When they first contact the MobiLink synchronization server, the server will send them a copy of its own public certificate. This certificate will bear the signature of the root certificate. The client can detect fake certificates by verifying that the root signature matches the public key in their copy of the root certificate.

2 Tell each client that it is to trust only servers whose certificates bear the signature of the root certificate. For Adaptive Server Anywhere clients, use the trusted_certificates security parameter. For example, you can tell an Adaptive Server Anywhere client to trust only the ent_cert.crt certificate by including this parameter in the ADDRESS clause of the SYNCHRONIZATION DEFINITION, as follows.

CREATE SYNCHRONIZATION DEFINITION test

SITE 'user001'

ADDRESS'security=certicom_tls{trusted_certificates=ent_cert.crt}'


To tell an UltraLite client to trust only the desired certificate, name the trusted certificate using the -r switch when running the UltraLite generator, as follows. Enter the entire command on one line.

> ulgen -c " dsn= UltraLite 7.0Sample;uid=dba;pwd=sql "

-r ent_cert.crt -j custapi

Sybase Adaptive Server Anywhere UltraLite Code Generator Version 7.0.0

Running UltraLite analyzer

Loading schema information

Loading SQL statements

Analyzing access plans

Generating source code for SQL statements

Generating source code for UltraLite schema

Saving source code into database

Writing source code to output file

3 When you start each MobiLink synchronization server, specify the name of that server's certificate file and the corresponding password. Enter each command on one line.
dbmlsrv7 -c "dsn= UltraLite 7.0Sample;uid=dba;pwd=sql"

-xtcpip{port=3333;security=certicom_tls{certificate=serv1.crt;

certificate_password=password3}}

dbmlsrv7 -c "dsn= UltraLite 7.0Sample;uid=dba;pwd=sql"

-xtcpip{port=4444;security=certicom_tls{certificate=serv2.crt;

certificate_password=password4}}



Section IX: Globally signed certificates


You can improve a deployment of MobiLink that involves multiple servers by assigning each server a unique certificate that is signed by a common root certificate. You can improve it further by using a certificate signed by a c ommercial certificate authority . Such a certificate is called a global certificate or a globally-signed certificate . A commercial certificate authority is an organization that is in the business of creating high-quality certificates and using these certificates to sign other certificates.

A global certificate has the following advantages:


· Security requires that both parties trust the root certificate. In the case of inter-company communication, common trust in an outside, recognized authority may increase confidence in the security of the system because a certificate authority must guarantee the accuracy of the identification information in any certificate that it signs.
· Security is enhanced when keys are created using pseudo-random data of high quality. The data used with the gencert utility is of cryptographic quality, but other, even better methods can be used in controlled environments.
· The private key for the root certificate must remain private. An enterprise may not have a suitable place to store this crucial information, whereas a certificate authority can afford to design and maintain dedicated facilities.

When using a globally signed certificate, each client must verify certificate field values to avoid trusting certificates that the same certificate authority has signed for other clients. This process is described in the next section.

Figure 6: Using a globally-signed enterprise certificate


MobiLink transport-layer security is based on Certicom SSL/TLS Plus libraries, which require elliptic-curve certificates. You can obtain a global certificate from Certicom, or any other certificate authority that can supply certificates in the correct format.


Obtaining a global certificate from Certicom