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

Certicom is a certificate authority that can provide certificates in the correct format. The procedure for obtaining a global certificate and a signed enterprise-level certificate from Certicom is as follows.

1 Use the reqtool utility, included with MobiLink transport-layer security components to create a server certificate and a global certificate request.

2 Copy the contents of the public certificate onto the clipboard.

3 Read the agreement and policies statement on the Certicom MobileTrust web site, located at http://www.certicom.com/mobiletrust/ecommerceserver/ . Choose a payment option.

4 Paste the contents of the public certificate into the web form located on the MobileTrust site. Only submit the public component of the certificate request. You must not disclose your private key .

5 A Certicom MobileTrust Registration Agent will process your application. Once processing is complete you will be contacted, usually by telephone, and supplied with a password you can use to obtain your global certificate from the MobileTrust web site.


For more information about this procedure, see the document reqtool.pdf, located in the bin or win32 directory in the MobiLink distribution.

Running the reqtool utility

The reqtool utility, included in SQL Anywhere Studio, creates server certificates and a global signature request document suitable for submission to Certicom. This utility is used as follows. The only key type compatible with MobiLink is elliptic-curve cryptography , or ECC.

> reqtool

-- Certicom Corp. Certificate Request Tool 3.0d1 --

Choose certificate request type:

E - Personal email certificate request.

S - Server certificate request.

Q - Quit.

Please enter your request [Q] : S

Choose key type:

R - RSA key pair.

D - DSA key pair.

E - ECC key pair.

Q - Quit.

Please enter your request [Q] : E

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

Country: CA

State: Ontario

Locality: Waterloo

Organization: Sybase, Inc.

Organizational Unit: MEC

Common Name: MobiLink

Enter password to protect private key : password5

Enter file path to save request : global.req

Enter file path to save private key : global.pri


The file global.req contains the public certificate and request information. Paste the contents of this file into the web form on the Certicom MobileTrust web site.

The file global.pri contains the private key for the enterprise certificate. This file is protected by the password you entered, but since the protection provided by the password is weak, you must store this file in a secure location.

A Certicom MobileTrust Registration Agent will process your application. Once processing is complete you will be contacted, usually by telephone, and supplied with a password that you can use to obtain your global certificate from the MobileTrust web site. Download the certificate soon afterwards. The certificate may be received in two different formats: a binary format and a text format. Both files contain the same information. In this case, you should store the text version of the certificate in a file called global.crt.

Using a global certificate as a server certificate

You can use your global certificate directly as a MobiLink synchronization server certificate. To do so, you must create a server identity certificate by concatenating the public and private certificates. Enter the following statement at the Windows command prompt.

copy global.crt+global.pri global2.crt

You can now start a MobiLink synchronization server, specifying the new certificate and the password for your private certificate. Enter the entire statement on one line.

dbmlsrv7

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

tcpip{security=certicom_tls{certificate=global2.crt; certificate_password=password5}}


You must also ensure that clients contacting your MobiLink synchronization server trust the certificate. To do so, you must tell the clients to trust the root certificate in the chain. In this case, the root certificate in the chain is a certificate held by the certificate authority.

By default, MobiLink clients trust certificates signed by the Certicom root certificate, or by the Sybase root certificate used to sign the sample certificate included with MobiLink. Hence, if Certicom signs your global certificate, MobiLink clients will automatically accept it as valid.

For better security, however, you should ensure that clients consider only the root certificate of your certificate authority to be valid.

You can tell an Adaptive Server Anywhere MobiLink client to accept only the Certicom root certificate by naming only this certificate in the Address clause of the SQL create synchronization definition statement:


CREATE SYNCHRONIZATION DEFINITION test

SITE 'user001'

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


To tell an UltraLite client to trust only the Certicom root 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 certicom.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


For convenience, the file certicom.crt is included in the MobiLink distribution, although you can obtain your own copy directly from Certicom, if you prefer.


Section X: Verifying certificate fields


Global certificates have one potentially serious flaw. Because the MobiLink clients, as configured above, trust all certificates signed by the certificate authority, they may also trust certificates that the same certificate authority has issued to other companies. Without a means to discriminate, your clients might mistake a competitor's MobiLink synchronization server for your own and accidentally send it sensitive information.

Similar precautions can be required in other scenarios, too. A company may use an enterprise certificate, but it may still be important to verify with which department a MobiLink client is connected.

This problem can be resolved by requiring your clients to test the value of fields in the identity portion of the certificate. Three fields in the certificate can be verified. You can verify any or all of these fields.


1 Organization

2 Organizational Unit

3 Common Name


To verify the fields, you supply the acceptable value. For example, the following code tells an Adaptive Server Anywhere client to check all three fields and to accept only the named values. Enter this SQL statement on one line.

CREATE SYNCHRONIZATION DEFINITION test

SITE 'user'

ADDRESS'port=3333;security=certicom_tls{ trusted_certificates=certicom.crt;

certificate_company=Sybase, Inc.;

certificate_unit=MEC;certificate_name=MobiLink}'


You can verify the fields from an UltraLite client in a similar manner. The precise syntax depends upon the interface used to build the application. The following fragment of C code accomplishes the same task when developing the UltraLite application using C or C++.

ul_synch_info info;

. . .

info.security_parms =

UL_TEXT( "certificate_company=Sybase, Inc." )

UL_TEXT( ";" )

UL_TEXT( "certificate_unit=MEC" )

UL_TEXT( ";" )

UL_TEXT( "certificate_name=MobiLink" );

. . .

ULSynchronize( &info );


This example verifies all three fields. You can instead choose to verify only one or two fields.

Verifying fields in certificate chains

When the first certificate is part of a chain, all the specified field values are checked in that certificate. If specified, the company name is also checked in all the other certificates, except for the root certificate. This arrangement allows for the case that the root certificate is held by a certificate authority. In this case, the field values of the root certificate will be different, as it is owned by the certificate authority, rather than your company or organization.


Using a globally-signed certificate as an enterprise certificate

Instead of using a global certificate as a server certificate, it is possible to instead use it to sign other certificates, as you would an enterprise certificate. This setup lets you combine the benefits of a global certificate and an enterprise certificate. The most important advantage is that you need not store the private key for your global certificate on the computer running the MobiLink synchronization server.

Note

Certificate authorities, at their discretion, may choose not to sell certificates that can be used to sign other certificates. Signing certificates without due diligence compromises security and may, potentially, discredit the certificate authority. For example, Certicom certificates cannot be used in this manner. For further information, contact your certificate authority.

To create such a setup, generate a unique certificate for each MobiLink synchronization server. When you do so, sign them with your global certificate.

The following example shows how two server certificates can be generated and signed by the global certificate.


> 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

Serial Number: 2000.02.29.06

Certificate valid for how many years: 1

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

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

Enter password for signer's private key: password5

Enter password to protect private key: password6

Enter file path to save server identity: serv6.crt

> 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

Serial Number: 2000.02.29.07

Certificate valid for how many years: 1

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

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

Enter password for signer's private key: password5

Enter password to protect private key: password7

Enter file path to save server identity: serv7.crt


The above commands generate two server identity certificates, intended for use with two MobiLink synchronization servers.

· The server identity certificate for MobiLink synchronization server #1 is serv6.crt
· The server identity certificate for MobiLink synchronization server #2 is serv7.crt

Both certificates are signed by global.crt, which in turn is signed by the Certicom root certificate.

You can start these two MobiLink synchronization servers with the following commands, entered one command per line.


dbmlsrv7 -c "dsn= UltraLite 7.0Sample;uid=dba;pwd= sql"-xtcpip{port=3333;security=certicom_tls{certificate=serv6.crt; certificate_password=password6}}

dbmlsrv7 -c "dsn= UltraLite 7.0Sample;uid=dba;pwd= sql"-xtcpip{port=4444;security=certicom_tls{certificate=serv7.crt; certificate_password=password7}}


In addition, you must ensure that each client trusts the Certicom root certificate. If you used a certificate authority other than Certicom, then you should ensure that your clients trust only that authority's certificate, instead.

The steps for ensuring that MobiLink clients trust only the Certicom root certificate are shown above.


Section XI: Using certificates with Palm clients


UltraLite applications running on the Palm Computing Platform can make use of digital certificates, just as can all other types of MobiLink clients. However, synchronization can occur in one of two ways. How a Palm application synchronizes determines which portions of the connection are protected and where the transport-layer security client configuration information must be stored.

An UltraLite application on the Palm Computing Platform can synchronize in two ways:


1 Through a direct connection to a MobiLink synchronization server.

2 Through HotSync or ScoutSync with a desktop computer, then by MobiLink conduit to a MobiLink synchronization server.


Using a direct connection


In the first case, all MobiLink client logic, including transport-layer security, is implemented on the Palm device. When such a Palm application synchronizes, all messages are encoded or decoded on the Palm device. These messages may pass through computers connected to the network, but the messages are protected during the entire route by MobiLink transport-layer security.

Figure 7: Synchronizing through a direct connection


Since all MobiLink client logic resides on the device, all client configuration settings reside on the Palm device, too. For UltraLite clients, use the -r switch on the UltraLite generator to specify the trusted root certificate.

Using HotSync or ScoutSync

In the second case, the Palm Computing Platform makes use of HotSync or ScoutSync to exchange information with another computer. These applications are intended to manage synchronization of personal data with a desktop computer. Depending on the configuration, the Palm device may exchange data either with the computer to which it is directly connected, or by means of a HotSync or ScoutSync proxy and a server conduit manager, on a second desktop computer located elsewhere.

Figure 8: Synchronizing through HotSync or ScoutSync


A user can initiate HotSync or ScoutSync-based synchronization either from the Palm device or from the cradle. At the other end, the HotSync or ScoutSync conduit manager invokes the MobiLink conduit DLLs. These DLLs contain the MobiLink client logic. They access the Palm device through the use of a HotSync or ScoutSync-specific API. HotSync or ScoutSync allows the DLL to read and write records to a Palm database located on the Palm device.

HotSync and ScoutSync allow synchronization over serial lines, phone lines, local-area networks, and wireless networks. However, this communication is not protected by MobiLink transport-layer security, as it is not directly part of the MobiLink system. Thus, HotSync or ScoutSync operating over a standard phone line, a public network, or a wireless modem leaves this portion of the communications channel vulnerable to attack.

Many of the related security issues can be improved through the use of software, such as virtual private networks, or through hardware, such as secure point-to-point routers. Your network administrator or the manufacturer of your particular conduit may be able to offer additional suggestions.

One simple approach that is often adequate is to use a Palm cradle to connect the Palm device directly to the computer running the MobiLink conduit DLLs. This approach offers protection because it limits access to data transferred via HotSync or ScoutSync.

Setting MobiLink client parameters when using HotSync or ScoutSync

When using HotSync or ScoutSync, the MobiLink client logic resides not on the Palm device but on a computer running the MobiLink conduit. Thus, MobiLink client parameters that control certificate field checking and trusted roots must be set on the machine running the MobiLink conduit.

There are two methods of setting these parameters:


1 Set the parameters in the ul_synch_info data structure and pass a reference to this structure as a parameter to the PalmExit call in the UltraLite application. The values are then passed automatically through HotSync or ScoutSync and used by the MobiLink conduit at the other end.

2 Create entries in the registry of the machine running the MobiLink conduit. This may be done using the configuration facilities provided by the HotSync or ScoutSync conduit manager. The means of setting these values and the location of the values in the registry is specific to the conduit manager.

Section XII: Security checklist



To be effective security must be an integral part of the development and deployment process. There is little value in using a secure mechanism such as MobiLink transport-layer security, then overlooking other access points to your system. While not necessarily exhaustive, this section provides a checklist, intended to remind you of ways you can address many common areas of weakness.

1 Limit access to the computer running the MobiLink synchronization server. The server requires access to the server certificate, which contains the server's private and public keys. The certificate password provides limited protection, however it may be visible to others using the computer if it is specified on the command line.

2 Limit access to the consolidated database server, which may or may not be run on the same computer as the MobiLink synchronization server. This database contains not only the master copy of your data, but the scripts that control the synchronization process. Ensure that all accounts have hard-to-guess passwords, particularly if they allow manipulation of sensitive data or settings. Likewise, ensure that no untrusted users of the computer have privileges that let them compromise your system. The easiest way to accomplish this is to limit access to the computer.

3 If the MobiLink synchronization server and consolidated database server run on different computers, secure the network that connects them. Currently, this can involve using dedicated network hardware that will authenticate and encrypt data between two network locations. You can also use software solutions that can encrypt TCP/IP communication from the port of one machine to the port of another machine. The use of Virtual Private Networks (VPN) or modern IP security protocols can also secure computer-to-computer connections.

4 Ensure all clients trust only one root certificate, the certificate used to sign your server certificate. By default, a MobiLink client trusts certificates signed by two different root certificates, namely, the Sybase and the Certicom root certificates. This default is convenient during development but should never be left in a deployed system. For Adaptive Server Anywhere MobiLink clients, the trusted certificates are specified using the trusted_certificates security stream parameter. For UltraLite MobiLink clients, use the -r switch of the ulgen utility.

5 Ensure all clients verify certificate fields. A certificate authority may use the same root certificate to sign certificates for other entities. Your clients will accept all these certificates unless your application uses the fields of the server certificate to verify that the certificate belongs to your entity or corporation. MobiLink clients can verify certificate ownership using the stream parameters certificate_company , certificate_unit , and certificate_name .

6 If your Palm applications use HotSync or ScoutSync, secure all connections and computers through which HotSync or ScoutSync transfers the data. MobiLink transport-layer security is designed to protect only the communication between a MobiLink client and a MobiLink server. When using HotSync or ScoutSync, it is the computer running the MobiLink conduit that is the client. Thus, transport-layer security protects only communication between this computer and the MobiLink server.

7 Limit access to MobiLink clients. Each client must keep a trusted copy of the public root certificate. If this copy is altered or replaced, a client may be deceived into trusting the wrong MobiLink server. This means of attack may expose sensitive information to an imposter, even if the information is stored in an encrypted manner on the client device itself.

Conclusion



If you have only a single server, the simplest setup is to create a self-signed certificate. The only true disadvantage is that the private key for the certificate must be held on the synchronization server, where it is harder to protect.

An enterprise root certificate is of particular benefit to organizations using more than one MobiLink synchronization server. In this setup, MobiLink clients need keep only a copy of this root certificate to recognize any MobiLink synchronization server issuing a certificate signed by this root certificate.

Commercial certificate authorities can benefit organizations that require the utmost in security. These organizations can help in two ways. First, the root certificates they use are of the highest possible quality, making these certificates somewhat less prone to attack. Secondly, commercial certificate authorities can provide a trusted third party when two companies wish to communicate securely but are not familiar with each other.

You can, and in some cases should, use the facilities provided to verify certificate fields. This precaution is particularly appropriate when using a globally signed certificate. In this case, you are unlikely to want your clients to trust certificates that your certificate authority has signed for other customers.

In all cases, you must ensure that the MobiLink command line and log file are secure. This is best done by using a firewall and by otherwise limiting access to the machine running the MobiLink synchronization server.

MobiLink transport-layer security is a flexible mechanism that lets you achieve the security important to your setup. The basic system allows you to keep information private, but certificates ensure MobiLink clients that they are talking to a trusted MobiLink synchronization server.

Legal Notice



Copyright © 2000 Sybase, Inc. All rights reserved. Sybase, the Sybase logo, Adaptive Server, MobiLink, and SQL Anywhere are trademarks of Sybase, Inc. All other trademarks are property of their respective owners.

MobiLink technology includes components supplied by Certicom, Inc. These components are protected by patents.

The information, advice, recommendations, software, documentation, data, services, logos, trademarks, artwork, text, pictures and other materials (collectively, "Materials") contained in this document are owned by Sybase, Inc. and/or its suppliers and are protected by copyright and trademark laws and international treaties. Any such Materials may also be the subject of other intellectual property rights of Sybase and/or its suppliers all of which rights are reserved by Sybase and its suppliers.

Nothing in the Materials shall be construed as conferring any license in any Sybase intellectual property or modifying any existing license agreement.

The Materials are provided "AS IS", without warranties of any kind. SYBASE EXPRESSLY DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES RELATING TO THE MATERIALS, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.

Sybase makes no warranty, representation or guaranty as to the content, sequence, accuracy, timeliness or completeness of the Materials or that the Materials may be relied upon for any reason. Sybase makes no warranty, representation or guaranty that the Materials will be uninterrupted or error free or that any defects can be corrected. For purposes of this section, 'Sybase' shall include Sybase, Inc., and its divisions, subsidiaries, successors, parent companies, and their employees, partners, principals, agents and representatives, and any third-party providers or sources of Materials.