Collecting security baggage on the internet

Collecting security baggage on the internet

ELSEVIER Collecting Security Baggage on the Internet S.H. von Solmsl and J.H.S. Geldenhuys* Department of Computer Science, Rarld @ikaarls Aucklandpa...

907KB Sizes 0 Downloads 27 Views

ELSEVIER

Collecting Security Baggage on the Internet S.H. von Solmsl and J.H.S. Geldenhuys* Department of Computer Science, Rarld @ikaarls Aucklandpark

2006, Jolzanrresbq,

Utriuersity, Box 524,

South Africa

[email protected] rarr.ac.za ’ [email protected]~c(~.~a

The PCM was introduced as a model to address security problems in unsafe computer environments.This works on a principal called baggage collection. The model describes how using baggage can solve security problems in complex computer environments, but does not state how this baggage is collected.This paper will provide a practical solution and implementation to this problem by describing how making use of Java and digital certificates can collect baggage. Keywords: PCM, Java, Trusted Third Party, Authorization Java Baggage Security Application, baggage

Applrt,

1. Introduction In [l] and [2] the reader is introduced to the Path Context Model (PCM) that can be used to address the security problems in complex and potentially unsafe computer environments.This model can be applied to WANs, LANs and VANS alike. From this statement one could therefore easily make the assumption that the PCM could be implemented on the Internet with relative ease.The problem with the Internet is that it is a much bigger and much more heterogeneous ‘network’ than a normal WAN or LAN. A very basic definition of the Internet would say that it is made up of a collection of above-mentioned WANs and LANs. In [l] the following statement is made: “The approach [PCM] was found to accommodate an amazing number of different environments. In fact the more complex the environment the clearer the model becomes,

0167-4048/98$19.00

0 1998 Elsevier Science Ltd

mainly as a result of the baggaging and access paths concepts.” Once again it would seem that the PCM could easily be implemented on the Internet. However, a closer look at the PCM identified the problem that it is not specified how this baggage is collected.This paper addresses this problem and then shows a practical way in which the PCM could well be used to address the security problems on the Internet. It should be noted that asymmetric encryption (public key encryption) plays a major part in the working of the proposed model.

2. The Path Context Model (PCM) Because the working of the PCM is rather complex the model makes use of complex formal grammars - the detail working of the model will not be discussed in this paper. Only the most important concepts and components of the model will be addressed. The PCM

consists of the following

l

The baggage

l

Security

validators

l

Security

profiles

components:

[I]

collector

337

Collecting Security Baggage on the Internet/S. H. von Solms and J. H. S. Geldenhuys

See Figure 1 for a representation

of the PCM.

Baggage Collector

Security Validator

I

--------L-------+

,

I

I

I I

I I

I I I

I I I-----------------

The baggage therefore defines the access path from the user - that submitted a request to access an object that resides on a remote machine - right up to that remote object. An access path is formed by all the different components that are used to execute the user’s request. This baggage is the minimum amount of information that should be collected that will accompany the user’s request through the network so that the security validator can assess whether the request should be allowed access to the desired object or not. [1,7] Figure 2 sh ows a typical access path from a system in America to a system in South Africa.The baggage in this case could be the IP-addresses of all the intermediate nodes along the way to the remote machine, e.g. (100.112.125.36; 124.32.147.11; 147.25.89.63; 123.45.147.78; 159.78.96.11).

J

Remote System

Figure 1: The Path Context

Model.

The baggage collector in the figure should be seen as a piece of code residing within a request travelling from a host system to a remote system. The request would probably require access to an object on this remote system. The baggage collector will collect information from all intermediate nodes, e.g. an IP-address, on its way to the remote system. Please note that the term ‘object’ in this paper is being used to refer to any piece of data, be it a program or a static piece of information that is to be retrieved. On arrival at the remote system the security validator will use the baggage from the baggage collector to determine whether the request can be allowed access to the required object. This is done by comparing the baggage received from the request with the security profile of the object. The security validator manages this process.The security profile of an object defines all the valid access paths to that object. A route that is not listed in the security profile of an object will result in a denial-of-access to that specific object.

338

America 100.172.125.36

Intermediate

ntermediete

124.32.147.11

147.25.89.53

South Africa

Intermediate

159.78.96.11

123.45.147.78

Figure 2: Baggage and access path in the PCM. When a request tries to obtain access to an object, the security validator is activated. The security validator can be seen as a firewall between the request and the object. The security validator compares the real access path that was followed by the request, (like the one in Figure 2) with the security profile of the object. The security profile of data object defines the valid and invalid access paths that can be followed by a request to that object. [1,7] This comparison will then decide whether access to the object is allowed.A visit to any untrusted node, i.e. a node not listed in the security profile or a node blacklisted in the profile of an object,

Computers & Security, Vol. 17, No. 4

will result in a request being denied access to the object. Access to an object is therefore only allowed if the access path i.e. the request’s baggage, is part of the object’s security profile. See Figure 3.

tination. Unfortunately neither the PCM, nor the APCM describes how this baggage is collected, i.e. how does the request and the intermediate nodes it visits communicate with each other to gather information (baggage) about each other? The remainder of the paper will address this problem by using Java and digital certificates.

;’ Security Profile V.“.“.”

4. How is baggage collected?

Object on remote machine

1

rYGzGC1

Figure 3: A Security

Profile.

A normal method of communication between the request and the intermediate node could make both the request and the node vulnerable to attacks from one another. It is therefore necessary that an organized and secure method of communication be established between the request and intermediate node for baggage collection purposes. This will ensure that the communication between the parties involved will take place in a structured fashion and at the same time protect both the node and the request.

In the figure the request has collected baggage on its way to the object it wants access to on the remote machine with the description of x.x.x.x. Let’s assume that x.x.x.x represents the access path stated in Figure 2. Since the security profile of the object has this access path specified, i.e. it can be deemed safe, access to the object will be allowed.

A structured form of communication can be implemented by using Java and digital certificates.The next section of this paper will describe a model that will safely collect baggage by making use of Java and digital certificates.

Baggage can be any type of information. The IPaddress of an intermediate node was used for illustrative purposes onlyWhat type of information to use for baggage will be discussed later in the paper.

The model for safe collection of baggage, will comprise of the following components:

4.1. Components

l

3. Problems with the PCM

By referring to a Trusted Third Party the authors make the assumptions that a certificate-based hierarchy is in place on the Internet that can be used by any user to acquire a secure digital certificates.This assumption is based on the model proposed in [4] and information found in [5].

It would seem that the PCM could be applied to the Internet with relative ease, this being derived from the statement made earlier in the paper taken from [l]. However, it has come to light that the PCM refers to baggage quite a lot without ever mentioning how the baggage should be collected. In both the PCM [1,2] and the APCM [7] security profiles (attached to every object) and baggage (collected by the request) are used to assure that the request has travelled by a secure path to reach its des-

A Trusted Third Party (TTP) for generation, ditribution, storage and verification of DCs

l

Digital certificates from a Certificate Authority DCs will be acquired from the TTP as will be described later in the paper.

339

Collecting Security Baggage on the Internet/S. H. von Solms and J. H. S. Geldenhuys

Authorization

l

Applets(AA)

This applet will contain the DC of the sender of the request as well as the request itself.

same for both models; i.e. to compare baggage collected by a request with the security profile of an object on a remote system. Proposed

l

Java Baggage Security Application

Path Context

model

Model

(IBSA)

The JBSA will be installed on the intermediate node along with the DC of the intermediate node. The different components of the proposed model are depicted in Figures 4 and 5. Figure 4 is taken from [4] that depicts a proposed Certificate Management System that is essential in the use of digital certificates. Figure 5: Components

of PCM and proposed model.

The working of the model depends on the assumption that all communicating parties on the Internet make use of a Java compliant WWWbrowser. It is also important to be sure that the baggage that the request receives from an intermediate node is correct as well as vice versa.The nodes as well as the request have to be forced to tell the truth when questioned about their identity. The following section will address the basic working of the model as well as how the communicating parties can be sure that the information they receive is correct. 4.2. Working of the model

Figure 4: A Certificate

Management

System.

Figure 5 also depicts the relationship between the components of the PCM and the new proposed baggage collection model. In this figure the AA consisting of the sender’s DC and the request from the sender, can be seen as the equivalent of the baggage collector in the PCM.The intermediate node remains the same in both models, except for the JBSA and DC that are added to the node in the new proposed model for security reasons as will be described later. The security validator’s function also remains the

340

A request is sent via the Internet from a host system to remote system. For this request to obtain access to the required object on the remote system, the route it follows has to be compared with one of the valid routes in the security profile of the object it requires access to. [1,7] If the route that the request followed corresponds to any one of the object’s security profile entries, access to the object is allowed, otherwise access is denied. For the request to determine the route that it has taken from its host system to the desired object, it must have communicated with all of the intermediate nodes along the way and collected information about these nodes, i.e. baggage. This is accomplished in the following way.

Computers & Security, Vol. 17, No. 4

Neither the node nor the request trusts each other. Therefore, for the two parties to communicate with each other there will have to be a process of identification between them. This is done with the help of DCs that can be obtained from the TTI? If a user on the Internet wishes to communicate with any other party on the Internet, or if they know that they are going to be part of a communication process on the Internet, they apply at a local TTP for a DC, an AA and a copy of the JBSA. The reason for keeping the Java Security Software (AA and JBSA) at the TTP is for convenience sake only. This software could also be bought from a vendor or downloaded from ‘trusted’web sites.The reason for keeping the Security Software at the TTP is to download it as soon as a DC is granted to the user as well as the fact that the TTP could be seen trusted. 4.2.1 Acquiring

l

l

l

l

Trusted Third Party

Digital Certificates

For a party to obtain a DC it has to give certain information to the TTP so the TTP can assure that the party is who it says it is. Information supplied by a user would typically be: l

his private key and can then use it to communicate with other users on the Internet. Any user on the Internet will be able to read the DC of another user because everybody will be able to decrypt it with the public key of the TTI? However, nobody will be able to steal another user’s DC or be able to masquerade as another user because of the encryption of the DC with the applicant’s public key To steal this DC the thief would have to be in the possession of the applicant’s private key See Figure 6 for an explanation of this process.

Prm = Private key of the lTP Pub,@& = Public key of the applicant

Name Identification

number

Figure 6: Application for a DC at a TTP.

Address Public key of an asymmetric key pair generated by the user. (The private key is kept secret by the user) Any other information TTP

deemed necessary by the

The information supplied by the party applying for the DC at the TTP will be encoded into a DC that will be encrypted with the private key of theTTP [5] as well as with the public key of the applicant.The latter will ensure that only the applicant will be able to decrypt the DC for use. The public key of the TTP will be made available to all users on the Internet.The DC is then sent back to the user that decrypts it with

In the figure an applicant requests a DC from his local TTI? Information such as depicted in the figure should be submitted to the TTP, along with any other information deemed necessary by the TTPThis information is verified by the TTP and used to build a DC for the applicant.The DC is then encrypted with the private key of the TTP as well as the applicant’s public key This unit is then sent back to the applicant for use during communication with other parties. 4.2.2 Java Security Software The reason why Java is used for the security software is the fact that Java is platform independent. After compilation Java is capable of running on virtually any hardware or software platform. [3] Another useful feature that is found in Java’s Security Model is the fact that a Java applet like the Authorization Applet in the

341

Collecting Security Baggage on the Internet/S. H. von Solms and J. H. S. Geldenhuys

model - can only make network connections back to its originating host and not to any other network station. [3,6] At this point it would be wise to state that the assumption is made that the intermediate nodes that are referred to in the paper are seen as intelligent PCs and not as the normal type network routers.The reason for this is to ensure that there exists a level of intelligence in the network that would be able to accommodate a language like Java. As mentioned earlier, the Java Security Software consists of Authorization Applets (AA) and Java Baggage Security Applications (JBSA).The AA will be used to include the request from the sender as well as the DC of the sender and will assist in communicating with intermediate nodes. The JBSA will reside on the nodes on the network. Communication will only take place between the AA and the JBSA on the node. The digital certificates and Java Security responsible for the following functions: l

l

l

l

Serves as a mechanism to identifji cating parties to each other.

Software

the communi-

Serves as a mechanism to convey baggage the intermediate nodes and the request. Ensure

the correctness

Ensure cess.

integrity

4.2.3 Baggage

during

is

between

of the baggage. the communication

pro-

collection

As a request is sent from a host system to a remote system, the request of the host - along with the host’s DC - is added to the AA. At this moment the 1X is still encrypted with the private key of the TTI? Before it is added to the AA it is also encrypted with the sender’s private key.The moment the AA arrives at an intermediate node, the AA and the JBSA of the node start communicating with each other. This is made possible by the fact that both pieces of software are written in Java. Now that a communication channel

342

has been established between the request and the intermediate node (the AA and JBSA), the two parties can be introduced to each other. 4.2.4 Identification JBSA

between

the AA and the

The moment the AA and the JBSA start communication it is important that the parties be identified to each other.This is done by making use of the DCs of the two parties.The AA can be seen as the ‘untrusted intruder’ and has to produce its DC first. The JBSA decrypts the DC with the public key of the sender as well as the public key of the sender’s TTI? On viewing the information in the DC the node will be assured of the identification of the AA. Any failure to decrypt the DC would imply a stolen DC.The same procedure applies to the JBSA to identify itself to the AA. This process ensures that both parties can identifjr with whom they are communicating. As soon as identification is complete, the methods in the AA and the JBSA that are concerned with the collection of baggage can be activated and the baggage can be transferred to the AA. This, however, can be a very difficult task. To ensure that the request can obtain access to the desired object on a remote machine, the baggage has to be carried along with the request within the AA. After carefully considering all types of encryption methods and hash functions it became apparent that hiding the baggage information from other nodes is quite easy. Nobody would be able to read the baggage within an AA, but it would still be possible for an intruder to add or remove pieces of baggage from the AA, which would make it impossible to gain access to a remote object. Adding or removing pieces of baggage from the AA would result in an access path that would not be accepted by the security validator that guards access to the remote object. The solution to the problem was found by making use of the security concept ofJava that limits an applet to only making network connections back to the host from which it originated. Identifying the AA and the JBSA to one another and then sending the DC of the

Computers & Security, Vol. 17, No. 4

intermediate node to the host system of the AA therefore collects baggage.The DC of an intermediate node it therefore used as baggage seeing that it already contains all the relevant information of the intermediate node. This form of baggage collection also ensure the following: l

No large or growing AA’s cluttering

with the TTP’s private encryption key as well as with the public key of the user.The encrypted certificate is then sent back to the user. See Figure 7 for a representation of such a certificate.

the network. ‘=“bwm

l

1

1

Only short bursts of network traffic to send DC’s back to the host system.

On arrival at the remote system the AA makes one last connection back to its host system to fetch all the baggage collected and then submits this baggage to the security validator to assess whether access to the desired object should be allowed or not. That, in short, is how the model works. Unfortunately it is possible for an intermediate node or an AA to give false information to the other party that needs it, by handing a stolen DC to the communicating party. Fortunately this can be avoided as will be discussed in the next section. 4.2.5 Correctness of baggage As mentioned previously, both the AA and the intermediate node need to be sure that the information they receive from the other is correct. Unfortunately neither of the two can trust the other to give the correct information. It is therefore necessary to implement a method to assure that the information they receive is correct. This is made possible by using the DCs again. Whenever a user applies at the TTP for a digital certificate he has to submit certain information about himself. The user also generates a public/private key pair for encryption purposes. The public key of the user’s pair is also submitted to the TTP. It is important to note that theTTP also has a private/public key pair for signature purposes. The TTP’s public key is made available to everyone on the Internet. The user’s public key, as well as the information that was supplied by him, is used to create a DC for the user as seen in Figure 6. The DC is then encrypted

IP Address ID number Name Telephone number Validity Penod

P%++.nt= Appl~cant’s PN,,

= lTP

Public key Private Key

1Public key

Figure 7: A Digital Certificate. When the user receives his certificate from the TTP, he decrypts it with his private key. This ensures that only the valid user of the certificate can unlock the certificate for use. Even if someone manages to steal the certificate he won’t be able to decrypt and use it. In some cases it would be possible to steal a DC and while in possession of it perform an exhaustive attack on it to try and derive the private key. However, this would be highly unlikely as the lifetime of a DC is limited by the ‘Validity Period’ field in the DC that states when a certificate is to expire. [5] This period is usually much shorter than would be necessary to break an encryption key by brute force. It is therefore more likely for a certificate to be revoked before a private key can be derived. As soon as an AA with an embedded request is sent from a user to access a remote object, the user’s certificate is also embedded in the AA. At his point the DC is still encrypted with the TTP’s private key. It is also encrypted with the applicant’s (user sending request) private key for reasons that will be explained later. When an AA arrives at an intermediate node, the two parties start communicating with each other as described in the previous section. When the node has transferred the baggage that the request wanted i.e. the DC of

343

Collecting Security Baggage on the Internet/S. H. von Solms and J. H. S. Geldenhuys

the node, the AA can also make use of the 1X system to assure that the baggage (IX) that it had received is correct. This is done in the following manner. After the request receives the certificate (baggage), it opens it up by decrypting it with the public key of the applicant (user) and the public key of the TTP that signed the 11C.The AA is now able to see the information about the node. The AA now encrypts a random challenge with the node’s public key and hands this encrypted challenge back to the node. The challenge might be a question like: “What is your IP-address?“. The node decrypts the challenge with its private key, responds to the challenge, encrypts the answer with its private key and hands it back to the AA. The AA decrypts the answer with the node’s public key and compares the answer with the IP-address it saw in the node’s DC. If the answer is illegible, i.e. it could not be decrypted with the node’s public key, the AA knows that the node doesn’t have the corresponding private key to the public key the AA used to encrypt the challenge and is therefore another node that is trying to masquerade as this node.The same procedure is applicable to the AA, as well as with the rest of the nodes on the route to the destination, including the destination node itself. The model described above solves the baggage collection problem in the PCM and APCM. The use of a TTP might still be a fictious idea but work is being done in this area. [4,5] J ava is also relatively safe, as can be seen in [3,6], but also in this area a lot of work will still have to be done. It should be mentioned at the end of this paper that even all the security methods in the model still don’t eliminate the possibility of a third party attack on the physical lines between the nodes in the network.The model will, however, also solve this problem, as the reader would have deduced by now. Any type of interrupt, i.e. a physical line breakage or power failure during a request will result in an access

344

path that will not appear in the security profile of the object that the request required access too. This will ensure that access to the object is not allowed and the request will have to be re-sent. It might still cause a rather large time delay, but the advantage of the Internet is that there isn’t just one route to follow to a particular destination. Replies that have been in interrupted will be dealt with in the same way.

5. Conclusion In this paper it was shown that both the PCM [l] and APCM [7] have neglected to specify a way in which to collect the baggage that a request has to collect on its route from a user that sent the request to an object on a remote system that the user wants to access. Making use of Java and digital certificates solves the problem. A Trusted Third Party (TTP) supplies participants on the Internet with Authorization Applets, (AA) Java Baggage Security Applications (JBSA) and digital certificates that can be used by both requests and intermediate nodes on the Internet for identification processes and baggage collection. The digital certificates serve as a method for identification between the request and intermediate nodes and are also used for baggage; i.e. information about the intermediate node to include in the access path the request has to adhere too, to gain access to a remote object. Java is used to simplify the communication process between the request and the intermediate node because of the fact that Java is platform independent. Java also supplies the model with the security feature of applets only being allowed to make connections back to their host system.This ensures safe communication between all the parties.

6. References [l] Boshoff, W.H. and Von Solms, S.H., 1989. A Path Context Model Addressing Security in Potentially Non-secure Environments, Computers G Security, 8(1989) pp. 417-425.

Computers & Security, Vol. 17, No. 4

[2] Boshoff, W.H. and Von Solms, Application of a path context approach security fundamentals, Infi~wmtiorz Age, _ April 1990, pp. 83-90. [3] Fritzinger, Security” whitepaper.txt

S.H., 1990. to computer Vol. 12 No 2

Steven, J. and Mueller, M., 1996. ‘yava http://www.javasoft.com/security/1996.

C yeafing security applications ozz tlze of Systewz, Department Computer and Systems Sciences, Stockholm Technology University & Royal Institute of http://www.entegrity.com/papers/-safrica.html. [4] Kapidzic,

N.

Global [email protected]

Management

Privacy Enlzancernei?t _fou Itzterrzet Electrorzic Mail: Part 2: Certificate Based Key Marzagemerzt

[5] Kent,

RFC

S., 1993.

1422 February

1993.

[6] Sterbenz, A., 1996. Atz evalcratiorz(zf theJava Security 12th Annual Computer Security Applications Conference, December 1996.

Model.

ArlOSS [7] Van Zyl, I? and Von Solms, S.H., 1992. A Model_for Opczz Systerrz Senrvity,Uniform Asia, 1992.

S.H. van Solms IS professor and Head of the Depdrtnlent of Computer Scirncr of the Rand Afrikaans Uniwrsity in Johannesburg, South Africa. Hr holds ‘1 PhD degree in computrr science. His main area of research is computer security, cpecifically trying to find new and more powrrful theorrtical models. The field of formal languages is used extensively in the descrlptions of such models. J.H.S. Geldenhuys is currently ‘1 PhD student at the Kand Afrikadns Umverrity in Johannesburg, South Africa. His studies xe concentrated on computer security, specifically security on thr Internrt dnd World Wide Web. Hr currently works for FosterMelliar as Solutions Manager with cecurq as his Mom field of expertise.

345