Certificate Status Validation in Mobile Ad-Hoc Networks Jordi Forné, Jose L. Muñoz, Francisca Hinarejos, Oscar Esparza Department of Telematic Engineering – Technical University of Catalonia { jordi.forne, jose.munoz, mfcampos, oesparza}@entel.upc.edu

Abstract Certificate validation is much more complex in Mobile Ad-hoc Networks (MANETs) than in conventional networks because online access to trusted authorities is not always guarantied. For that reason, we require new solutions to overcome both the lack of infrastructure and also the limited capabilities of several user devices. In this article, we study the application of different mechanisms for certificate validation in MANET and we present a cooperative mechanism for certificate validation suitable for MANET.

Keywords. Authentication, Security Architecture, Security in MANETs, Certificate Validation, PKI

Introduction MANETs (Mobile Ad-hoc Networks) are cooperative networks that allow wireless nodes to establish spontaneous communications. As stated in [8], such networks are envisioned to have dynamic, sometimes rapidly-changing, random, multihop topologies which are likely composed of relatively bandwidth-constrained wireless links. MANETs may operate in isolation (stand-alone), or they may have gateways to fixed networks. In this last case, the MANET is called “hybrid”. Hybrid MANETs are expected to be deployed as an extension to the traditional infrastructure networks. Also notice that the hybrid behaviour can be temporary due to the situation in which an ad-hoc network may be sometimes stand-alone and sometimes connected to the Internet e.g. a subway network in which a MANET user is connected to the Internet while being at the station and disconnected while travelling. This is the scenario that we consider in this article: MANET nodes that can be connected or disconnected from the Internet. On the other hand, trust and security are basic requirements to support business applications in this scenario and the public key scheme is the preferred underlying mechanism to provide security services. In a public key scheme, each participant has two keys: a public key (i.e. known by everybody) and a private key (i.e. secret). The announcement of the public key is performed using a signed document called Public Key Certificate (PKC) that binds the participant with her public key. The entity that signs the certificate is called “certificate issuer” or “Certification Authority” (CA). In the literature, there are several ways of managing security and trust in MANETs based on public key cryptography. These approaches basically differ in the degree of decentralization of the mechanisms deployed for issuing, publishing and revoking the certificates. There are decentralized architectures especially designed for MANETs, in which the nodes of the MANET participate in the certification process. The main architectures of this type are the self-organized architecture [1] and the architecture based on threshold cryptography [2]. From our point of view, interoperability issues such as the local validity of the certificates and the lack of support for mobility heavily restrict their usability in the hybrid scenario. In our opinion, the use of an external Public Key Infrastructure (PKI) is a useful and standard way to provide these security services. Moreover, PKIs are currently widely used to provide secure communications over different network topologies. PKIs use Trusted Third Parties (TTPs) known as Certification Authorities (CAs) to digitally sign certificates, ensuring that a particular public key belongs

to a certain user. The certification process is performed according to a standard centralized and publicly known policy. However, current PKIs are designed for centralized, wired and well-connected networks, so adopting PKIs for MANET is not an easy task. Mobile users are expected to move across different networks. When the user is in a network with connection to the PKI, she can use all the PKI services such as get a certificate, launch a status query, etc. However, users may be disconnected from the PKI when they require a real-time PKI service. In this sense, the certificate status checking is a critical PKI service because applications must check, at the time of usage, whether a certificate is valid or it has been revoked prior to its prescribed validity period. In this article, we review the current adaptations of PKI certificate validation for MANET and we show why the existing solutions are not efficient enough. After that, we present a new efficient validation mechanism for hybrid MANETs. Our approach is based on a Certificate Revocation List, to which we add an extension that allows any node to build a hash tree, which is a suitable structure to efficiently answer to status checking requests. Finally, it is worth to mention that we have implemented and evaluated our proposal.

Certificate Management in Mobile Ad-hoc Networks In this section, we describe the main public key approaches for managing trust and security in MANET. In general, these approaches can be classified as: •

Decentralized (internal). The nodes of the MANET participate either fully or partially in the certification process.

•

Centralized (external). Authorities outside the MANET control the certification process according to a global policy.

In the fully decentralized PKI schemes for MANET, like Capkun et al. [1], the nodes of the MANET themselves issue, publish and revoke the certificates. The certificate management is autonomous and self-organized because there is no need for any trusted authority or fixed server and all the nodes have the same role. In this system, like in PGP (Pretty Good Privacy) [11], each user is her own issuer. Certificates are stored and distributed by the nodes in a fully self-organized manner. Each certificate is issued with a limited validity period and it contains its issuing and expiration times. Before a certificate expires, the owner can issue an updated version of the certificate, which contains an extended expiration time. Authors call this updated version the certificate update. Each

node periodically issues certificate updates, as long as the owner considers that the user-key bindings contained in the certificate are correct. Trust is achieved via chains of certificates. Like in PGP, the nodes build trust paths certifying from one node to other, as in a friendship circle, forming an authentication ring to achieve the trust relationships with other nodes of the MANET. Another group of public key schemes for MANET is based on threshold cryptography [2]. These schemes are partially decentralized and they were first proposed by Zhou and Haas in [12]. The idea behind these schemes is to distribute certification duties amongst network nodes. A (k,n) threshold scheme allows the signing private key to be split into n shares such that any k nodes could combine and recover the signing key for a certain threshold k
problem.

Public Key Management Schemes

Degree of decentralization Infrastructure

Self-certification

Threshold cryptography

PKIX

High

Medium

Not required

An administrative

Standard PKI currently

authority is required to

working in the Internet.

Low

initialise the n servers. System availability

Acceptance of credentials

Relays on the possibility

Requires k from the n

Subject to the connection

of building a trust path

server nodes working

availability to PKI servers.

from local data.

properly.

Low

Low

High

Each user can revoke her

A node is revoked if it

The owner or the issuer can

certificate.

receives k accusations from

revoke the certificate.

in the Internet Credentials revocation

other nodes. Credentials Status

Local

Local

Global

The user considers the

The credential is

Depending on the status

certificate valid if she can

considered valid if it

that comes from the PKI.

find an updated trust

accumulates less than k

path for it in her local

accusations in the user’s

cache.

local list.

Validity of the certificate

Local

Local

Global

Support for users mobility

Low

Low

High

A user who leaves a

The user needs a new

MANET and joins to a

certificate issued by k

periodically update her

new one has to create

servers of the new

certificate (certificates are

new trust relationships

administrative

issued for a long time).

Validation

The user only needs to

environment. TABLE I. SUMMARY OF PKI APPROACHES FOR MANETS.

Certificate Status Checking In a PKI, the revocation process starts with a request to revoke a certain certificate. In general, the owner of the affected certificate or the certificate issuer, also called Certificate Authority (CA), can create revocation requests. The revocation request is sent to a revocation manager, which is usually also the CA. In this case, the CA is also responsible for periodically issuing and distributing the revocation status data of the certificates under its control. There are two standardized Certificate Status Validation mechanism: the Certificate Revocation List (CRL) [10] and the Online Certificate Status Protocol (OCSP) [9]. The Certificate Revocation List (CRL) is the simplest way of distributing status information. It is a "black" list of the identifiers of the certificates that have been revoked. The CRL is distributed using non-trusted intermediate authorities called repositories. The integrity and authenticity of the CRL is provided by an appended digital signature. There are two standard versions of X.509 CRLs. X.509v1 CRLs are inherently flawed due to scalability concerns (that is, the size of an X.509v1 CRL could easily grow beyond acceptable limits) and functionality limitations specifically related to the inability to extend the CRL with additional features when needed. X.509v2 CRL introduces the idea of extensions. Certain extensions have been defined on a per revoked certificate entry basis, and others are defined on a per CRL basis. The other standard certificate status validation scheme is the Online Certificate Status Protocol (OCSP) [9], in which status data distribution is performed using trusted intermediate authorities called responders. OCSP offers the possibility of gathering knowledge of the status of a particular certificate without the need to acquire a complete CRL. In OCSP, the status of certificates is available through a request/response mechanism. An OCSP client issues a status request for a particular certificate and sends it to an OCSP responder. Upon receipt of a request, the responder searches the status information in its local database, it creates and signs a response with the corresponding data, and sends it back to the client. The responder may return a response meaning that the certificate supplied in the request is 'good', 'revoked' or 'unknown'. Notice that as the responder is a trusted authority, the client has to be able to verify the responder's identity. This means that the client needs to have a responder's certificate which she can trust.

Finally, the distribution between the issuer (CA) and the responder has to be done in a secure manner. This is usually performed by means of a CRL. CRL and OCSP are designed for wired and well-connected networks and therefore it is necessary a way of distributing the status data of PKI certificates from the CA to the MANET nodes. In the literature, there are proposals that investigate the feasibility of using CRL flooding to distribute status data in MANETs [3] [4]. The main conclusion of these works is that CRL presents a limited scalability for PKI because CRLs can grow with time, they may become large, and MANET nodes may have limited network, processing and memory resources. On the other hand, in [5] there is a proposal called ADOPT (Ad-hoc Distributed OCSP for Trust) to adapt OCSP to MANET. According to the proposal there are three different kinds of nodes: server-nodes, caching-nodes and client-nodes. The server-nodes act as OCSP responders. The authors assume that server-nodes will have connectivity with external PKI repositories or responders to get updated status data. With respect cachingnodes, they store OCSP responses issued by server-nodes and distribute them to clientnodes when they detect a request that fulfils freshness requirements.

Why a new proposal? The hybrid scenario is a dynamic environment in which a MANET can be connected to the fixed network or it can be autonomous. The MANET topology changes randomly and mobile users continuously join and leave the network. Besides, MANET nodes may have limited network, storage, processing and memory resources. We present a new proposal because neither CRL nor ADOPT completely fulfil the requirements of this scenario. We start analysing the CRL approach for MANET. The main drawback of CRLs is that they can grow with time and become eventually quite large (up to several megabytes). A large CRL distributed to each node requiring status checking validation implies a great waste of network resources, and forces the nodes to have enough cache. Therefore it is inefficient to broadcast CRLs. But the CRL has an interesting feature for MANET: it is an offline approach. An offline approach means that the status data can be distributed by means of non-trusted entities. The CRL is pre-computed (offline) by the CA and then, it is distributed to repositories. The CRL contains all the information necessary to depict, during a window of time, the status of the set of certificates controlled by the CA. Notice

also that a node that has a valid CRL can broadcast it to provide valid status information during the CRL validity period without having connection with any external PKI entity. ADOPT has also deficiencies in the scenario considered. In first place, when a user needs to check the status of a certificate, the responder has to be accessible or, lacking that, a valid response has to be found in a caching-node. Notice that this is not always possible. During a disconnection period of time it may not be possible to find a status response in the MANET since caching-nodes have only partial information of the status of certificates (for instance, there will be no status information available for a certificate that has never been requested). In second place, in ADOPT, each certificate may have an associated OCSP response, so the number of responses in the caching-nodes of the MANET can be high depending on parameters such as certificate population, OCSP responses validity period, number of requests for different certificates, etc. The main advantage of OCSP is clearly the small size of the responses necessary to perform a status checking compared with the size of a complete CRL. The result of the previous analysis is that the certificate status checking system for the hybrid MANET should be offline because connectivity is not always guaranteed and also provide a protocol for status checking that provides a small response size because MANET is a constrained environment. Below, we describe a proposal that meets these requirements.

Collaborative Status Checking Based on Hash Trees In this section, we propose a collaborative scheme for PKI status checking in the hybrid 1

MANET scenario . The status information must flow from the CA that has the database of revoked certificates to a node placed in the MANET that is asking for the status of a certificate. In the first phase, the CA creates a CRL with a signed extension. The CRL entries of the revoked certificates together with the signed extension allow third nontrusted parties to build an efficient structure, a hash tree, to answer status checking requests. Then, this “extended-CRL” is distributed to PKI repositories. In the second phase, a non-trusted node gets the extended-CRL and becomes a status checking repository for other MANET nodes. Finally, in the third phase, the MANET nodes can

1

This proposal has been implemented within the European UBISEC project [13]

use an efficient protocol to get the status checking information from an available MANET repository. Below, we give a more detailed description about the different phases and steps of the status checking distribution mechanism. PHASE I. CREATION AND PUBLICATION OF THE EXTENDED-CRL The aim of this phase is to create a structure called “extended-CRL” and its publication in a PKI repository. To do so, the CA creates a standard CRL with all the identifiers of the revoked certificates. Then, the CA adds an extension that will be used to perform an efficient protocol for status checking between nodes inside the MANET. The CA follows the next steps (see Figure 1): 1. The CA creates a “to-be-signed-CRL” (tbs-CRL) from the identifiers of the certificates that have been revoked. 2. Then the CA creates the extension. To do so, the CA creates a hash tree using the identifiers of the certificates that have been revoked. Below (see also Figure 1), we explain the basics of the hash tree creation (see [6] for further details of the creation algorithm and implementation issues): a) The nodes of the lower level of the tree are called "leaves". Each leaf represents an entry for a revoked certificate. C1, C2, C3, and C4 represent the identities of four revoked certificates in ascendant order. b) Adjacent leaves are concatenated and hashed to form nodes in the upper level. H() is a hash function, and '|' indicates concatenation. Then, H(A|B) = E, and H(C|D) = F. c) The process is repeated recursively until there is only one node at the top level called root. The root is a digest for all the data stored in the tree. In this case, H(E|F)= root. 3. The extension basically consists in the root value of the hash tree, the CRL validity period (VPCRL) and the signature of these data. Notice that the CA signature in the extension is necessary to provide an authenticated root to the node which in turn is necessary to reconstruct an authenticated version of the hash tree. 4. The CA creates the extended-CRL signing the tbs-CRL and the extension. 5. Finally, the CA distributes copies of the extended-CRL to the designated PKI repositories, in the same manner as a standard CRL.

VPCRL

(2.c)

root = H(E|F)

(3)

F= H(C|D)

(2.b)

CA signs the information

E= H(A|B)

A = H(C1) B = H(C2)

VPCRL

C = H(C3) D = H(C4) (4)

Certification Authority

(2.a)

(1)

Signed by the CA

Extended-CRL

tbsCRL

(5) CA certificate

PKI Repository

Standard CRL Identifiers of revoked certificates

Figure 1. Phase I: Creation and Publication of the Extended-CRL

Notice that the root of the hash tree has been signed by the CA with the same time stamps as the CRL, so the hash tree will be valid during the same time and will provide the same information that the CRL. It is also remarkable that the extended-CRL is only slightly larger than the standard CRL as we show later in the performance evaluation. PHASE II. BECOMING A MANET REPOSITORY In this phase a node that is taking part in the MANET becomes a new repository. The best nodes to become repositories are those nodes that have enough bandwidth, processing, storage and battery resources. The node that is going to become a revocation repository has to follow the next steps (see also Figure 2): 6. The node obtains the extended-CRL from a PKI repository using a connection with the fixed-network or it obtains a copy of the extended-CRL from another MANET repository. 7. The node creates the hash tree using the extended-CRL and following the same algorithm that the CA (as explained in phase I). 8. Then, the node checks that the root value of the tree created from the CRL entries matches the signed root value contained in the extension. 9. At this moment, the node acting as repository can start listening to status checking requests from other MANET nodes.

Notice that while the CRL is valid there is no need for further synchronism between the CA and the repositories. PHASE III. MANET CERTIFICATE STATUS CHECKING In this phase, the MANET provides the status information to a node that needs to validate the status of a certificate. The node uses a Service Discovery Protocol (SDP) to find a repository inside the MANET for status checking. Once the repository has been located, the node starts the status checking protocol. The protocol for status information exchange is based on the hash tree structure and it allows checking the integrity of a single CRL entry with only some hash material plus the root signed by the CA (included in the extension). On one hand, this is much more efficient than broadcasting the entire CRL. On the other hand, the mechanism is offline (the only trusted authority is the CA), which is a very good feature because the MANET may be disconnected. Next, we depict the protocol by means of an example (see also Figure 2). Let us suppose that a node wants to check if certificate identified by C1 is revoked. 10. The node uses a SDP to find a repository inside the MANET for status checking. 11. The node sends the identifier of the certificate that is going to be verified (C1) to the repository. 12. The repository searches the certificate in the hash tree. In this case the certificate is found and the repository sends the hash values B and F and the signed root. 13. The node verifies the received data. To do so, the verifier hashes C1, then the result is concatenated with B and hashed again, and the result is finally concatenated with F and hashed again. The data is considered correct if the last hash value equals the signed root, that is: root=H((H(C1)|B)|F).

PKI Repositry Extended-CRL

? = (8) (7)

(6) (6)

MANET Repository

(9) SDP

VPCRL

(10)

F B C1

C1 ?

(11)

VPCRL

+ B + F

(12) ? = F B

Verifier

(13)

VPCRL

Figure 2. Phase II: Becoming a MANET repository and Phase III: MANET Certificate Status Checking Notice that as the root is signed by the CA, it is just as impractical to create falsified values of B and F as it is to break a strong hash function. In case the certificate is not revoked, the 2

repository sends the adjacent leaves to the requested certificate . In any case, the data that the repository needs to send to a node to perform the status checking can be placed in a single UDP datagram using 802.11 link-layer.

Performance Evaluation In this section, we evaluate the bandwidth efficiency of the proposed status checking protocol and we compare it with CRL downloading. Network Simulator 2 has been used to carry out the simulations. The simulated scenario is a hybrid MANET with a gateway acting as repository and we use the parameters shown in table II:

2

Area

100x100m

Number of nodes

100

Max speed

100m/s

Transmission range

120m

Mobility Model

Random WayPoint

MAC

IEEE 802.11b

See [6] for further details of the algorithms and implementation issues

Bandwidth

11 Mbps

Transport protocol

UDP

Number of PKI certificates

100000

Revocation percentage

10%

Status checking requests per validity period

2

TABLE II. SIMULATION PARAMETERS.

Figure 3 shows the instantaneous bandwidth in the repository. The instantaneous bandwidth has been modelled as the bandwidth that would be necessary to send all the data in the transmission queue in a second.

Bw(t) hash tree

Bw(t) straight CRL

120

80 60 40 20

Bw (Kbps)

BW (kbps)

8000

100

7000 6000 5000 4000 3000 2000 1000 0

0

Figure 3. Instantaneous bandwidth in the repository. In the Figure is observed that the bandwidth is approximately constant around order of tens of Kbps for our protocol, whereas peaks of several Mbps are observed for CRL. The effect of these peaks is due to CRL downloading. In the simulated scenario, the node keeps the CRL in cache until the expiration date. Therefore, nodes do not make new requests towards the repository until the expiration of the cached CRL. This is why, around the expiration date, the repository receives the greatest number of requests to download the updated CRL. On the other hand, we have measured also the average bandwidth consumption and we observe that in the case of straight CRL downloading, we need more than 3Mbps in the repository which is a relevant figure compared with the 70Kbps required by our protocol. In CRL, the rest of the nodes of the MANET require a bandwidth around 1Mbps while for our protocol it is about 20Kbps. The bandwidth consumption in the rest of nodes is more or less the same because the mobility pattern used causes that these nodes have been at the same distance of the repository in average during the simulation. Finally, it is also remarkable that the size of the extended-CRL is only increased in a 3%

regarding a standard CRL of 100 entries and only a 0.3% for a CRL of 1000 entries (as shown in Table III). NUMBER OF REVOKED

CRL SIZE

EXTENDED-CRL SIZE (BYTES)

OVERHEAD (%)

CERTIFICATES

(BYTES)

50

2250

2391

6.3 %

100

4250

4391

3.3 %

1000

40250

40391

0.35 %

TABLE III. OVERHEAD INTRODUCED BY THE EXTENDED-CRL (USING RSA-1024).

Conclusions Decentralized public key approaches such as self-certification and threshold cryptography provide mechanisms for certificate management inside the MANET, but the local validity of the certificates and the lack of support for mobility heavily restrict their usability in the hybrid MANET scenario. To solve these problems a centralized PKI approach can be used, but in this case standard certificate status checking mechanisms such as CRL and OCSP fail to meet MANET requirements: CRL presents a bandwidth scalability problem for the MANET, while OCSP requires an accessible trusted responder. In this article, we have presented a solution for these problems based on an extended-CRL. The main advantage of this extended-CRL is that the repositories can build an efficient structure based on an authenticated hash tree to respond to status checking requests inside the MANET, and saving bandwidth. The save is around 40 times in average for the sample simulated scenario. The performance enhancement is obtained at expenses of slightly increasing the size of a standard-CRL to include the signed hash tree extension. Another advantage of our approach is that it is fully offline, in other words, the CA is the only trusted party of the system and therefore there is no need for online trusted responders. Finally, it is worth to mention that we have developed a proof-of-concept of our system under the IST UBISEC project [13]. The development consists in the status checking client for MANET [14], which we have programmed in Personal Java to assure execution by limited devices, and the CA/repository software that we have programmed with Standard Java as part of our Certificate Validation Test-bed (CERVANTES) that can be downloaded under GNU licence from sourceforge [15].

References [1] S. Capkun, L. Buttyan, and J.P. Hubaux, “Self-Organized Public-Key Management for Mobile Ad Hoc Networks”, IEEE Transactions on Mobile Computing, Vol. 2, no 1, pp. 52-64, 2003. [2] Y. Desmedt, Y. Frankel, “Threshold cryptosystems. In Advances in Cryptology— Crypto’89”, the Ninth Annual International Cryptology Conference, Proceedings, Lecture Notes in Computer Science, vol. 435. Springer-Verlag, pp. 307–315, 1989. [3] S. Eichler and B. Muller-Rathgeber, “Performance analysis of scalable certificate revocation schemes for ad hoc networks,” in Proceedings of the 30th Conference on Local Computer Networks (LCN). 2005. [4] H. W. Go, P. Y. Chan, Y. Dong, A. F. Sui, S. M. Yiu, Lucas C. K. Hui and Victor O. K. Li, “Performance Evaluation on CRL Distribution using Flooding in Mobile Ad Hoc Networks (MANETs)”, in Proceedings of the 43rd annual ACM southeast regional conference – Vol. 2. pp. 75 – 80, 2005 [5] G. F. Marias, K. Papapanagiotou, V. Tsetsos, O. Sekkas, P. Georgiadis, “Integrating a Trust Framework with a Distributed Certificate Validation Scheme for MANETs”. EURASIP Journal on Wireless Communications and Networking Volume 2006, pp. 1–18, DOI 10.1155/WCN/2006/78259. [6] Jose L. Muñoz, J. Forné, O. Esparza, and M. Soriano, ``Certificate Revocation System Implementation Based on the Merkle Hash Tree,'' International Journal of Information Security (IJIS), vol. 2, no. 2, pp. 110-124, 2004. [7] PKIX Chapter of the IETF. www.ietf.org/html.charters/pkix-charter.html [8] RFC 2501. S. Corson, J. Macker. “Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations”, 1999. [9] RFC 2560. M Myers., R. Ankney, A. Malpani, S. Galperin, and C. Adams, “X.509 Internet Public Key Infrastructure – Online Certificate Status Protocol – OCSP”, 1999. [10] RFC 3280, R. Housley, W. Ford, W. Polk, D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”, 2002. [11] P. Zimmerman. “The Official PGP Users guide”, MIT Press, 1995. [12] L. Zhou and Z.J. Haas, “Securing Ad Hoc Networks”, IEEE Networks, Vol. 13, no 6, pp. 24-30, 1999. [13] http://www.ubisec.org [14] http://isg.upc.es/pki_pmi/revocation/ [15] http://sourceforge.net/projects/cervantes/