Problem of Trust in Issuance of Foreign Pseudonym Certificate in Cross Domain Scenario

Get Complete Project Material File(s) Now! »

Problem of Trust in Issuance of Foreign Pseudonym Certificate in Cross Domain Scenario

SeVeCom project’s solution provides security and privacy for Vehicle Communication have addressed a single PKI domain solution. In that security model which is based on Public Key Cryptography and Infrastructure, they provide Message authentication and integrity, confidentiality, non-repudiation, entity authentication, access control, accountability while keeping privacy of vehicles through concept of pseudonym and short term certificates. To explain SeVeCom model in more detail, here the key concept and overall procedure of acquiring certificate and validation process is explained.
In a VC domain each vehicle (X) has one Long-Term Identification that is similar to Vehicle Identification Number (VIN). This identifier contain a pair of cryptographic key (SK x, PK x) and some attributes like model of vehicle, engine type, year of production, and etc. As stated in [1] the identifier is unique, life time, and registered in offline mode based on agreement between manufacturer and Certificate Authority (CA) of the domain. Vehicle generates bunch of key pair (SK1V; PK1V); :::; (SKiV; PKiV) in its HSM console and sends public keys together with Long-Term Identifier to a configured CA. CA identifies the vehicle and generated and sign pseudonym, puts its own identifier and then send them back to vehicle. Since pseudonyms of other vehicles in the domain is issued and signed with same trusted CA, they have verified identity of each other which provides a base line for other cryptographic operation specified in security requirement during communication among vehicles such as Message authentication and integrity, confidentiality, non-repudiation, entity authentication. In other word, vehicle uses one of temporary and pseudonym identities and key pair to sign messages what they want to pass to other entities. Design and implementation of this procedure is topic of another project by [4] which uses certificates as identifiers and develops LTCA and PCA to handle process of issuing different types of certificates and also PRA which is the authority to perform pseudonym resolution to identify the real identity of a pseudonym certificate.
But what if a vehicle crosses boundaries and drives into domain B from domain A? To preserve privacy SeVeCom suggest a new identifier name Foreign Pseudonym Certificate (FPC). FPC is again a pseudonym certificate which inherits identity of foreign PKI domain B, therefore, vehicle looks like other vehicles in domain B while communication with them and intruder is not able to identify it by format of pseudonym it uses. To do this, vehicle should proves its identity to DCA is domain B and then DCA signs pseudonym key pairs and issue new pseudonym certificates with set of identifies which looks like other identifier in domain B.
But in stated FPC solution there are two aspects that need be addressed. First and main one is that when talking about more than one VC domain, many questions would be aroused about PKI trust model. Each DCA has its own CP which is set of standards such as length of signing keys and algorithms used or Proof of Possession requirements in Certification Requests, where to store keys, request should be offline or online and etc. [12]. Therefore, establishing trust between CAs of various domains become difficult and complicated. Furthermore, another question is that to which level domains can put trust on each other. In real life scenario VC domains can be states or countries. Due to many factors such as diplomatic relationship, industry standard DCA in domain A may highly trust domain B. Therefore, it issue FPC for all categories of vehicle including type (Trucks, cars, motorcycles), importance (VIP, diplomatic, emergency, ordinary cars), manufacturer, year of production and etc. Or domain A put low level of trust on vehicles from domain C, so it just give foreign certificate to emergency and diplomatic vehicles. Making decision about these criteria depends on domains policies but technology should provide tools to realize these policies in practice.
Second aspect that needs to be addressed is the topological design of PKI trust model for VC. Unlike CA in one domain, relation between top CA in each domain (like countries) could be very loose. Is it possible to set up a Top CA for an area like European Union? What are the risks or advantages? Is it possible to establish cross certification between each two domains? What bout scalability of the PKI trust model in future?
Following sections in this chapter answer seconds question about Topology of PKI trust model and then introduce and formulate criteria as an answer the first one.

Topology of CAs in PKI Trust Model

Since introducing asymmetric cryptography and concept of Public Key Cryptography (PKC) main drawback of symmetric cryptography was solve [13]. The problem was how to share the secret key between security entities. Using PKC each entity needs to have their own private key and public of other entities so that they can leverage it to establish secure communication channels IPSec, SSL/TLS or sending secure messages through SMIME or PGP.
But a new problem aroused which was distribution of public keys. As [13] states “The goal of a public key infrastructure (PKI) is to enable secure, convenient, and efficient discovery of public keys.” In PKI concept, digital certificate binds identity of each entity to its public key [13]. To become valid and creditable, these certificates should be signed by another entity that both parties trust in. There are two approaches for establishing trust between PKI entities: Web of Trust and Certificate Authority (CA). As [13] defines in web of trust approach public key holder “can make publicly known whose keys they trust to be authentic. As a member of this infrastructure, one can decide whom to trust as an introducer of new keys, to a lesser or stronger degree. If the resulting web of keys and trust relationships allows one to establish a link between oneself and the target identity, then communication can take place.” In other word, as a non-hierarchical infrastructure authenticity of a public key has a direct relations with authenticity and number of intermediates (or your friends) who introduce you to the other party you want to communicate. Web of Trust like other non-hierarchical structures suffers the problem of scalability beside potential adversary such as impersonation attacks in a way that intruder can pretend to be authentic person and deceive a node in infrastructure. As a result all other parties who trust that node will trust the intruder as well. Web of Trust is a trust model which was introduce with PGP (Pretty Good Privacy) which is a communication security protocol and software mainly designed to protect email communication [15].
But the other approach which more widespread is using CA in PKI. PKI which is uses a synonym to PKI based on CA was introduced to address the problem of securely distribution of public key of principles who want to communicate. As [14] states “accepted solution is to have trusted nodes known as certification authorities (CAs) digitally sign data structures known as certificates that state the mapping between names and public keys.” CA as a trusted third party (TTP) proves identity of all principle and signs their certificates. But that solution which is called Single-CA obviously cannot be implemented because of following problems:
 It is inconvenient, insecure, and expensive to get a certificate from a CA in distance.
 In any security policy it is recommended to change the keys after a certain period of time. Of course CA is responsible for signing newly generated keys and also revoking the keys which have been compromised. Depending on key expiration period and compromise of the keys, this put huge amount on overhead on CA.
 And as a non-technical issue Single CA model end with a monopolization of information security structure of whole world by a single entity.
To solve these issues there should be more than one Single CA in the world. Each domain (e.g. organization, city, county, state, country or even continent) should have their own CA. Now consider that two principles in two different domains want to have a secure communication. The application used for secure this communication channel could be range from Secure MIME (S/MIME) [16], SSL/TLS [17] in Web application and VPN connection or IPSec [18] for securing Network layer of ISO model [19] between two network router. This raises the issue of cross-domain trust in PKI. Many models have been introduced by researchers in academies and also more practical ones by major information security trust companies to address this issue. Beside cross-domain PKI trust solution two other principles is PKI are designed which mainly try to help A Single CA with its work load and identity check of certificate requester:
 Delegated CA: In order to decrease overload on a CA, it can delegate its responsibility of signing certificate to sub-ordinate CAs. These subordinate CAs are trusted and their certificate is signed by CA. In an organization, CA can give responsibility issuing certificate of organizational units (OU) to CA of that OU. CA here is responsible of certification policy (see Chapter 3) and controlling subordinate CAs.
 Registration Authority: Process of issuing certificate can be divided into two steps verifying. Verifying identity of public key holder and issuing digital certificate itself. Registration Authority (RA) gets identity of the principle who requests of certificate. This verification could be though checking email address, home (or office) address or impersonal meeting [14]. If verified, RA send the request to CA and CA signs it and issue a digital certificate for that principle (Note that depend of certificate policy of a domain, key pair can be also generated by CA itself. Moreover, technically issuing a certificate includes signing digital certificate info together with public key which is explained in chapter 3.
While PKI domains can leverage any of above two solutions, when it comes to cross-domain interrelation problem, a number of PKI trust models have been designed. The main practical models that are used in industry are introduced and their specification, advantages and disadvantages are explained.
As it is shown in figure 2.1, CA 1 trusts principles of domain B by certifying (i.e. signing digital certificate) of CA 2. In this way relying parties is of domain one can trust subscribers of the other domain. In other world as EnTrust explains CA 1 “acting as an agent for its community of relying parties, evaluates the risk of accepting certificates issued by the other authority, and places the appropriate controls in the cross certificates that it issues” [24]. As risk assessment process, CA of one domain investigate the CP of other domain and based on that decides which subscribers are allowed on communicate with its relying parties in context of specific business application. An example is that subscribers of Sales department of Organization B are certified to use their cryptographic keys for digitally signing emails when communicating with replaying parties in Organization A.
Direct Cross certification is bidirectional, therefore, CA of domain B also certifies subscribers of domain A by reviewing its certificate policy and then signing digital certificate. In this model there is no trusted third party that acts as a hub and grantees trustworthiness of CAs of different domains. The main drawback of this model, as Entrust states, is that “cost of the risk assessment associated with entering into the trust relationship is prohibitive when the number of relationships is more than a small number” [24]. Consider that number of PKI domains increases then CA of each domain should evaluation risk of each and every domain itself which for a Complete Graph: If graph K has n Verticle then Kn has n(n − 1)/2 edges which forms a sequence number of 0,1,2,3,6,10,15,21, 28, 36, 45.
That means a PKI with 8 domains should do 28 risk assessments, evaluate the certificate policy, issuing certificates and managing revocation. Here the assumption is that CA itself acts as RA. Figure 2.1 demonstrate Direct Cross Certification: Hub Certification Authority 2.2.
To overcome the scalability issue of direct cross certification model. A trusted third party (TTP) comes to action. Its responsibility is assessing risk of trusting PKI domains by reviewing certification policies, then checking and validation of identities, signing CAs public key and finally issuing a digital certifications for CAs of all domains. This means that TTP accepted the security risk of subscribers of all domains so relying parties in those domains can start secure communication with them. Of course transferring risk to a third party comes at its cost. These TTP has different name in PKI industry such as Root CA, Hub, trust anchor and Trusted CA. [14] calls them configured CAs as in many application like Web Browser which leveraging SSL/TLS Digital certificate of these CA are stored and configured to be used by Web browser of relating parties. To verify certificate of subscribers which is signed directly or indirectly (with DCA or other sub-ordinate CAs that in the end form a certificate chain) by RCA, Relying parties retrieve RCA certificate and do the actual verification using embedded public key. Something specific about RCAs is that their digital certification is self-signed. This is because they are trust anchors and supposed to be trusted by other PKI domains Worldwide. Therefore there is no governmental or State CA above them to sign their certificates. Mozilla among other Web browser companies publish list of RCA which they configured in their web browser. The list include number of commercial brands such as EnTrust, Verisign and etc. [20]. Figure 2.2 shows the architecture of Hub Certification Authority. In this model Hub act both as CA and RA.
Of course the model solves scalability issue of direct cross certification by proposing a StarGraph concept vs. CompleteGraph in which number of edges is equal to vertices plus 1: V = K-1, Where K is number of edge and V number of vertices.
But as the size of domains and principals who are from various geographical location increase which cause new problems for hierarchical CA model. (Real-World Problems of PKI Hierarchy) categorized real life drawbacks of above this model:
 Technological, which is the distribution of information about certification revocation. Certification Revocation list (CRL) and Online Certificate Status Protocol (OCSP) have been developed to handle revocation problem which put large amount of overload on CAs due to request and response signals. Technically explaining about them is out of scope of this report.
 Administration concerns about including CP under which certificate is issued for CA or subscriber and also evaluation of CPs applied in different domain against each other. These problems have been solved in X509v3 standard which is used for implementation (see Chapter 3). The other administration problems are self-signed certificate of RCA which is still unsolved.
Third model is hybrid of two other models in which it separate CA and RA role of hub. Hub acts as RA and after verifying identity of DCAs distribute authentication token. Similar to direct cross functional, this model suffers from scalability issues. Figure 2.3 illustrate this model:
Explained PKI trust models addresses cross domain scenarios. In each PKI domain like an organization, city, state or county any of these models can be implemented which in most cases result in hybrid models. A widespread example is organizations that use hierarchical model in their own domain but CAs directly cross certify each other. This PKI relation could be between two commercial companies that enable their employees to establish secure email communication though S/MIME. In next section some real life example to cross-domain PKI trust model are introduced in which domains ranges from state owned organization to countries.

Example of Implemented Cross-Domain PKI Trust Model

This section of report review real of example to Cross-Domain PKI trust models. These models are created to orchestrate independent PKI domains which use different CPs that mostly result in loosely coupled architectures.
As Peter Alterman, Senior Advisor to the Federal PKI Steering Committee states, US Government in Paperwork Elimination Act of 1998 mandates all US federal agencies to provide electronic government services by 2003 for citizen. Infrastructural solution to establish secure communication channels to implement services like secure email or digital signature was realized through a Federal PKI. Aim of US Federal PKI is to « create a cross-governmental, ubiquitous, interoperable Public Key Infrastructure and the development and use of applications which employ that PKI in support of Agency business processes” [8]. In addition, the U.S. Federal PKI “must interoperate with State governments and with other national governments » [8]. Therefore, a cross functional PKI trust model was need to provide interoperation among national government. The first proposed model was a hierarchical Hub Certification Authority which a RCA which is responsible for writing and enforcing CP and implementing digital certificate operations. But there are four arguments against it:
 First is privacy issue in a way that this PKI solution enables the government to aggregate too much personal information of US citizens in a single place and make that information available to Agencies. This concern is not true about private sectors like shopping website where personal information are anonymous, but information stored in governmental agencies unlike commercial website, are not anonymous.
 Second argument is that Federal Agencies concerns about any security agency which is in charge of RCA. They insist that a « PKI run by another Agency cannot possibly satisfy their unique, mission-based requirements » [8]. The technical translation of it is that agencies prefer to have their own CP in their PKI domains due to their security concerns.
 Third argument is that in absence of a single dominant PKI solution vendor who would be become in charge of design, implementation and maintenance. Winning invitation to tenders (ITT) would have a huge benefit for any private vendor and of course a massive loss of other ones.
 Finally implementing and managing a new single PKI imply huge cost to government. Therefore, US Congress mandate Federal agencies to implement their PKI solution with their existing budget.

Table of contents :

1 Preliminaries
1.1 Introduction
1.2 Background
1.3 Related Works
1.4 Problem Definition
1.5 Research Goal and Contribution
1.6 Methodology
1.6.1 Explicated Problem
1.6.2 Outline Artifact and Define Requirements
1.6.3 Design and Develop Artifact
1.6.4 Demonstrate Artifact
1.6.5 Evaluate Artifact
1.6.6 Communicate Artifact
1.7 Audience
1.8 Limitations
1.9 Thesis Outline
2 Cross-Domain PKI Trust Model
2.1 Problem of Trust in Issuance of Foreign Pseudonym Certificate in Cross Domain Scenario
2.2 Topology of CAs in PKI Trust Model
2.2.1 Direct Cross Certification
2.2.2 Hub Certification Authority
2.2.3 Hub Authentication Authority
2.3 Example of Implemented Cross-Domain PKI Trust Model
2.3.1 US Federal Bridge Certification Authority
2.3.2 Canada
2.3.3 EuroPKI
2.3.4 Other Samples
2.4 Proposed Topology for Cross-Domain PKI Trust Model
2.5 Assurance Level of Security Practices and Trust Degree of LTC
2.5.1 Security Threat
2.5.2 Evaluation of VPKI Domain Security Practices
2.5.3 Evaluation of Subscriber Certificate
3 Design and Modeling
3.1 Scope and Assumptions
3.2 Design and Modeling
3.3 Digital Certificate standard and communication protocol
3.3.1 Certificate Signing Request
3.3.2 X509v3 Certificate
3.3.3 Communication protocols
4 Implementation and Performance Measurement
4.1.1 OpenSSL and Cryptographic Algorithm
4.1.2 C++ and IDE
4.2 Performance Measurement
5 Conclusion and Future Works
6 Bibliography 

GET THE COMPLETE PROJECT