• Ingen resultater fundet

In this chapter, the general design of the project was outlined. The different components as well as their connection to each other were described. The project consists of a Key Manager, a shell extension, a File Server, a Service Server, a Print Server, a Print Capability Server and a cryptographic library.

The chapter described the components function in the project and basic re-quirements for the components. The rere-quirements were built on the previous description of cryptographic access control and key management. The actual implementation was not discussed, but some design suggestions were proposed.

Chapter 6

Implementation

In this chapter, the implementation of the project will be described. The im-plementation is built on the design from the previous chapter. Figure 5.1 will be used as reference for the overall design. The seven parts1of the project will be described with references to the source code.

Because the project is a part of the CryptOS[Cry06] project, it was necessary to implement the project in theCprogramming language. The idea with CryptOS is to design and implement and entire operating system build on cryptographic access control. The current plan is to build the operating system on top of an existing kernel like the L4 micro-kernel[Gro06]. These kinds of micro-kernels only allow development inCand assembler. Cwas, therefore, the most obvious choice for the project.

This chapter first describes the data structures used in the project. Then, the implementation of the different parts from the design section will be described from the bottom up, i.e. the cryptographic functions, the Key Manager, the servers and then the Shell build on top.

1The seven parts of the project are: Key Manager, Shell Extension, File Server, Service Server, Print Server, Printer Capability Server and Cryptographic Functions.

6.1 Data structures

In the previous chapters, keys and key rings were introduced. To handle this in Cit is necessary to define a data structure that is appropriate for the data they contain. Furthermore, RPC connections are used for data traffic and requires that the data transmitted is contained in data structures. In this section, these different data structures will be described.

6.1.1 CAC Keys and Key Rings

The Key Manager’s most important data structure is the CAC Key. The CAC Keys are handled in the key manager and grouped in key rings to allow for key ring based access control. The table below(table 6.1) show the attributes within a key and their data types.

Attribute Type Description

sid int A unique key identification number.

type int Type of key

(Read/Write/Local/Keyring/Print/

Link/Service etc).

owner char[] The contact person for the key.

filename char[] The file/display name.

ip char[] The IP address

path char[] The path if the key is local.

symkey char[] The key for symmetric encryption.

pubkey R RSA PUBLIC KEY The public key.

prikey R RSA PRIVATE KEY The private key.

next key* Pointer to next key.

prev key* Pointer to previous key.

Table 6.1: The contents of a key and data types.

This project only uses the key described in table 6.1. This key data structure is used to handle keys to files, key rings, services, and printers. The files and key rings can be on a server or local. As well, the keys can be read/view or write/change. All this information is handled by the type attribute. The different types are enumerated with the following names:

{CHANGE KEYRING, VIEW KEYRING, CHANGE KEY, VIEW KEY, WEB KEY, PRINT KEY, LINK KEY}

6.1 Data structures 55

There is no attribute indicating whether a file is on a server or on a local drive.

For this purpose, the ip attribute is used. If it is a local file, the attribute is set to 0. The private and public keys are defined by the implementation of RSA used in this project (see more in section 6.2). These two types of keys are structs and contain data such as key size, exponent, and modulus. The private key has additional information about the prime exponent etc., so that the implementation can use the Chinese remainder theorem for faster signing.

View keys do not use the private key, and link keys have no keys at all, since they point to another key (more about this in next section).

The final two attributes are pointers to other keys, specifically to the previous and the next key. These two attributes allows the keys to be linked together in a linked list. It would have been possible to neglect these two attributes and create a linked list structure that contains a key and two pointers. Doing so could save a little memory, but the current solution makes it very simple to handle keys and the programmed code easier to understand.

The keys are defined under the cryptographic functions inkeys.h. The methods to maintain the key rings are under the Key Manager in theKeyRing.cfile.

6.1.2 RPC Structures

RPC connections require structures to be defined for communication between servers and clients. RPC connections only accept pointers to data, and therefore a pointer to achararray will be interpreted as a pointer to the firstchar.

In this project, it was necessary to define the structure for RPC communication as follows:

streamcontains a block of data to add to a file (thebuffattribute). In addi-tion, it has information about the session id (connection number between server and client) and the size of the block of data.

data is similar to the stream element, but is only used for server replies.

Therefore, it does not contain a session id. Thebuffattribute has a fixed length.

dataElem is used to send to a file server when a file is uploaded. The data element (dataElem) has session id, file number, hash (signature) of the file, the public key (key size, modules, exponent) and information about whether to create a new file or update an existing (thetypeattribute).

requestis used for the two way communication between the key manager and a Service Server. The structure contains the actual request (text) and information about which symmetric key to use(KeyID). TheKeyID allows the Service Server to handle several tasks with different keys. The client should specify which key to use.

An additional structure is defined on the Printer Server to handle the list of print jobs. It has a jobIdand a pointer to the nextjobId. The structure can, therefore, be used as a simple linked list.