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.

Section II: What is public-key cryptography?

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.

Section III: What is a digital certificate?

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.

Section IV: How certificates are used in MobiLink synchronization

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.

Section V: Self-signed 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.

Making a new self-signed certificate

•  
  
  > 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

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.
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.

Using a self-signed certificate

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

1 Supply a copy of the certificate to all clients. When they first contact the MobiLink synchronization server, the server will send them a copy of the public certificate, self.crt. The client can detect fake certificates by comparing the one sent by the server with the copy they already have.

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)

  )

  
  > 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


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.

3 When you start the MobiLink synchronization server, specify the name of the server certificate file, serv1.crt, and the corresponding password. Enter the entire command on one line.

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

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

  certificate_password=password}}

  
  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.

  
  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.

  
  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.

  
  All conditions are extremely important. The chain of certificates is only as strong as its weakest link.
  
  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.

  
  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.

  •  
    
    > 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:

  
  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.

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


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.

Section VII: Certificate chains

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.



Section VIII: Enterprise root certificates

· 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.
Creating the certificates