Our Logo  

Distributed Systems Lab 2003


Home Page
News & Feedback
Lab Organization
Lab Environment
Task Description
Overview
Lab 1
Lab 2
Lab 3
Lab 4
Certification Authority
WWW Tutorial
HTTP Tutorial
FAQ
Downloads

Certification Authority


This chapter gives a brief introduction to network security, digital signatures, and public key certificates. It also provides a description of the security architecture of the lab examples.

An Introduction to network security

The ShareMe system is a distributed application in which peers (clients and servers) exchange messages over an insecure communication network. In some cases it is necessary to protect messages in transfer.

A security policy specifies which messages are protected against which threats, and which security mechanisms are used for this purpose. Before defining a security policy for the ShareMe system, we have to determine what is to be secured, i.e., to analyze possible threats.

The security threats in our case fall into the following categories:

  • Eavesdropping : intercepting and reading messages by unintended recipients
  • Replaying : using previously sent messages to gain another principal's privileges
  • Message tampering : intercepting and altering messages intended for other recipients
  • Masquerading : sending/receiving messages using another principal's identity

Messages can be protected against eavesdropping by employing a security service of confidentiality (or privacy). This security service is usually implemented by encryption. However, we do not consider eavesdropping a security risk in the ShareMe system, because the clients do not require the search request and responses to be kept secret (especially, since the server publicly offers files, this does not make sense in our case).

Serial numbers or timestamps can be used against replaying because they ensure the uniqueness of messages. For instance, at time T1 a client may send a request with certain parameters to server S1 and obtain a response. At a later time T2, the same client can send another request with the same parameters to S1. This time, however, a third party intercepts the response coming from S1 and replaces it by the old response from S1. Since the request parameters are the same, the old response matches perfectly, and the client cannot detect the replay. If timestamps or serial numbers were used, this problem would have been detected by the client. In the ShareMe system, we do not protect communication against replaying.

Integrity services prevent message tampering . They protect messages against unauthorized modification. We provide this type of protection for search messages by applying digital signatures. Client messages can be modified by an intruder, but the server would notice it because the verification of the digital signature of the search request would fail. Also server replies could be modified. However, this can also be detected immediately by verifying the reply's digital signature.

Authentication services protect against masquerading . All ShareMe search requests and responses are authenticated by applying digital signatures. As you can see by applying the single security mechanism of digital signatures, we can protect requests against both tampering and masquerading.

Digital signatures are a security mechanism based on public key (also called asymmetric) cryptography. In a public key algorithm two cryptographic keys are used: one key is public, and one key is private and thus must be kept secret by its owner. If we denote the operation of encryption with the public key with E and the operation of decryption with the private key with D , then it must hold that E(D(Message)) = Message . In other words, the two keys are mathematically related. However, by knowing the public key it must be computationally infeasible to compute the private key (if the keys are of sufficient length) to ensure the security requirements.

If we compute a hash value (e.g., using MD5 as in the lab) of the message and encrypt it with the private key, this is called a digital signature of the message. Since only the owner knows her private key, she is the only person who can compute her digital signature. This property is similar to the uniqueness of hand-written signatures. Digital signatures have one additional property: They are also document-specific. This means that the same person would compute different digital signatures for different documents. If timestamps were used additionally, even the digital signatures of the same document signed at different times would be different.

The process of decrypting the digital signature of a message with the public key of the sender, is called signature verification . For this operation it is necessary to have access to the sender's public key which should be published in a public directory service (the DSG CA in our case). This means that anybody can verify the digital signature who has access to the sender's public key.

Instead of encrypting and decrypting a hash value of the actual message, we could also encrypt/decrypt the whole message. However, since the process of encrypting or decrypting is time consuming, usually only the hash value is used as the basis for the digital signature of a message.

The Certification Authority

If you had never seen somebody's hand-written signature, then you would not be able to verify it if you saw it on a document. For this reason, credit cards have to bear the owner's hand-written signature. Since it is rather difficult to forge a hand-written signature perfectly, the whole security of the system relies on the assumption that a hand-written signature is owner-specific. Additionally, the signature verifier has to trust the bank which guarantees that the card signature really belongs to a certain person.

The private key used for digital signatures is just a number, so it is not necessarily owner-specific. However, the owner can compute her private key herself and store it in such a way that nobody else can read it (e.g., on a disk protected by a password). Then she can bring her public key to a trustworthy institution (like the bank in the above example), provide a proof of identity, and on the basis of these informations the trustworthy institution can guarantee that a certain public key is really related to a certain person. The trustworthy institution is usually called Certification Authority (CA). The CA must be trusted by all parties.

Public Key Ceritificates

The guarantee for the binding between a public key and its owner is provided in the form of a certificate , a data structure which contains the owner's name, the CA's name, the owner's public key, the validity period of the certificate, and the CA's digital signature (e.g., X.509v3 certificates have such an internationally standardized certificate format (joint ISO and ITU-T)). To verify whether a certificate comes from a trusted CA, it is necessary to obtain the CA's public key first. Typically such public keys are already contained in the shipped programs (e.g., your Web browser) or are distributed via other channels (e.g., on floppy disks).

In contrast to the hand-written signature, a certificate and thus the corresponding public key have a limited validity period. Since several public key algorithms exist that can be used for digital signatures, it is important to encode in the certificate which one was used to create the certificate.

In the normal case, the certificate (actually the public key it certifies) can be used to verify digital signatures during the time period as indicated by the validity attributes of the certificate. However, if the owner or her CA find out that the private key has been compromised, they will immediately revoke the certificate. For this purpose the CA has to put all revoked certificates (issued by this CA) into its Certificate Revocation List (CRL) to publicly announce the revoked certificates. The information about the validity of a certificate can be obtained by sending a request to the CA which maintains the list of all valid and another one for the revoked certificates.

How to use the DSG CA

In the lab, we do not deploy a full-fledged security architecture using certificates, validity periods and certificate revocation lists. Actually, what we call DSG certification authority is not a certification authority but only a quasi-secure key exchange facility. What we support in the lab is that every peer can create a public/private keypair and register the public key at the DSG certification authority. Other peers can then query the DSG CA for the public key of other peers. We implicitly assume that nobody tampers with the messages exchanged between the peers and the certification authority during the registration and/or querying phase of public keys.

The DSG certification authority can be accessed using CORBA. The CORBA interface of the DSG CA is shown below and consists of three methods for un/registering and retrieving public keys. See the task description of lab 3 for further details.

            
module CorbaCAImpl {
  exception CorbaCAException { string msg; };

  typedef sequence KeyType;
  typedef sequence ListType;

  interface ICertificationAuthority {
    boolean registerKey(in string owner, in KeyType key, 
            in string password) raises (CorbaCAException);
    boolean unregisterKey(in string owner, in string password) 
                          raises (CorbaCAException);
    KeyType getKey(in string owner) raises (CorbaCAException);
    ListType registeredKeys() raises (CorbaCAException);
  };
};
          

Using the DSG CA at home

If you are implementing the lab at home, you can start the DSG certification authority locally on your machine. The full implementation of the DSG CA is included in the download package and uses the CORBA ORB integrated in the JDK 1.4.1. All you have to do is to start the ORB and then start the certification authority implementation. The latter will create a file called RNUEKeystore.ks which permanently stores the registered keys. Thus, you have to create and register your keypair only once, the certification authority will persistently store your registration!

Make sure you pass the same port you used to start the ORB as parameter/configuration option to the certification authority and your ShareMe implementation, i.e., ensure that you modified your property file accordingly. The two command lines below show a sample startup of the ORB and the DSG CA.

            
orbd -ORBInitialPort 10050

java at.ac.tuwien.infosys.rnue.implementation.ca.StartDsgCA localhost 10050
          

Since the implementation of the DSG CA is only for demonstration purposes, we did not provide a convenient way to shut down a CA. Thus, you have to kill it on the command line ;( The same applies to the ORB!

Hint: If you are working under Windows, it might be helpful to execute the above commands preceded by 'start'. Windows will then execute them in a new console and not block the current one.

If you want to obtain more details about using CORBA and Java, we recommend the Java IDL documentation which can also be downloaded from the download section . Especially the introductory-level 'Hello World' tutorial helps you get started.

Here are some important rules for dealing with the DSG certification authority:

  • Never start your own certification authority in the lab environment!
  • Your submission has to work with our certification authority as it is available in the lab (see the property file description ).


Powered by MyXML Last update on: 2003-03-13
© 2001 Distributed Systems Group