PUBLIC-KEY INFRASTRUCTURE

UFCFVN-30-M - Computer & Network Security

A Research Coursework

Prepared by
Kiran Kumar Mohanraj - 20054954
MSc Cyber Security
University of the West of England, Bristol

1
 TABLE OF CONTENTS

1. LAB TASK ----------------------------------------------------- 3

1.1 Task 1: RSA Key Cryptanalysis ------------------------------------------------ 3

1.2 Task 2: Creating a Certificate Authority (CA) ------------------------------------ 4

1.3 Task 3: Using your CA to Issue Certificates ---------------------------------- 6

1.4 Task 4: Deploying Certificates in OpenSSL HTTPS Server ----------------------- 8

1.5 Task 5: Deploying Certificates in Apache HTTPS Server --------------------------- 10

1.6 Task 6: Impersonating a Website (Man-in-the-Middle) -------------------------- 12

1.7 Task 7: Alternative Approaches to (Certificate-Based) PKI (Research Task) ---------- 14

1.8 References ----------------------------------------------------------------------- 16

2
1. LAB TASK
1.1 Task 1: RSA Key Cryptanalysis

To find the RSA public key, the following details are provided:
N=0x8ee32e2bdc9175272b19d9d64667b3869411e62b090bb16c50cabf0b76353ebcda48f9ae
02d0e27c75e2d5c0bff5c0bab5519609e96428fd86d968a27c619
e=0x11f87
p=0x39340499bcb48d0899db332321af58fc9d0c8424d5992fe255da980c4a2e117
Figure 1 show the procedure for RSA Encryption and how public keys are generated.

Figure 1 RSA Encryption

For this task, we use SageMathCell for carrying out the mathematical calculation. Using the
above shown formulas, we derive the value of d (public key) as shown in Figure 2.

Figure 2 Calculations for finding RSA public key

The RSA public key is:

D=212970789819308989496319984031463550864888286220194795883202797339460347
843642415393930260585719593497173918429552932948432647895271870832538104832
743 (in decimals)

3
1.2 Task 2: Creating a Certificate Authority (CA)

Before creating a Certificate Authority, we need to setup the configuration file (openssl.cnf).
To use this file, we need to create some directories and sub-directories. These steps are
illustrated in Figure 3.

Figure 3 Configuration file setup

Once the setup is done, we create a self-signed certificate for our CA. Figure 4 shows the
command for self signing a certificate. The outputs of this command is stored in ca.key and
ca.crt files. The ca.key stores the private key of the CA and ca.crt stores the public-key
certificate. The details provided for self-signing a certificate are shown in Figure 4.

Figure 4 Self-signed Certificate creation for CA

Figure 5 and 6 shows the content of the certificate. The subject and issuer are same which
proves that it is a self-signed certificate. In Basic Constraints, the CA is set TRUE, this shows
that this certificate can sign another certificate. This proves that Certificate Authority has been
created successfully.

4
Figure 5 Self-signed Certificate

Figure 6 Self-signed Certificate

5
1.3 Task 3: Using your CA to Issue Certificates

Firstly, we need to generate RSA public-private key pairs. Figure 7 shows the commands used
for key pair generation. To view the key pair, we use the command “openssl rsa -in server.key
-text”.

Figure 7 RSA key pair generation

Now, we create Certificate Signing Request (CSR) with the previously generated server key
pair. This CSR is then sent to the CA to generate a certificate for the key and company name.

6
 Figure 8 Creating CSR

Figure 9 shows the commands for issuing the certificate where the previously generated CSR
is converted into X509 certificate using the CA’s private key and public-key certificate.

Figure 9 Issuing X509 Certificate

7
1.4 Task 4: Deploying Certificates in OpenSSL HTTPS Server

Firstly, the DNS should be configured. We need to add our entry to /etc/hosts file so that the
machine recognizes the our website without changing the DNS. This entry maps the hostname
to the localhost. Figure 10 shows the demonstration of the above steps.

Figure 10 Configuring DNS for our hostname

For configuring the web server, we combine the key and certificate into a single file and then
launch a web server using openssl s_server command. Figure 11 shows that the server is in
ACCEPT state, indicating server is running.

Figure 11 Configuring web server

The port 4433 is the default port which the server can listen. The URL for accessing the server
is: www.UWEKiranMohanraj.com:4433/
When we load the URL, we could see an error, which says connection insecure, is displayed in
the web browser. In Advanced options, we could see a message that our URL uses invalid
security certificates. This is because, the root certificate which we created is not recognised by
browser, thus invalidating our certificate.

8
 Figure 12 Accessing the web server using our URL

In order to overcome this error, we manually add our certificate to the browser by navigating
to certificate manager and importing ca.crt. Figure 13 shows the our root CA has been added
as trusted certificates.

Figure 13 Trusted Certificates of Firefox

Once this setup is done, we try to load our URL in the brower. We could see our index.html
being loaded and contents of it has been displayed (as shown in Figure 14).

Figure 14 Successfully accessing our web server

9
1.5 Task 5: Deploying Certificates in Apache HTTPS Server

For this we use Apache web server for deploying the certificates. Firstly, we add a VirtualHost
entry to the Apache configuration file (default-ssl.conf). Figure 15 shows our entry added to
the configuration. The ServerName entry specifies the name of the website, while the
DocumentRoot entry specifies where the files for the website are stored

Figure 15 VirtualHost entry

Once the setup is done, we run series of commands for starting the apache server. Firstly, the
confirguration file is tested, then the SSL module is enabled, finnaly the apache server is
configured for HTTPS and restarted. Figure 16 shows the series of commands executed for
doing these steps.

Figure 16 Configuring Apache server

Finally, the web browser is launched for loading the 2 URLs. Figure 17 shows the loading of
https://uwekiranmohanraj.com and Figure 18 shows the loading of
http://uwekiranmohanraj.com. The difference that we can notice is that URL with https shows
a secure connection whereas the http shows connection insecure. The https URL is secure
because the data transfered from the server to the browser is encrypted using SSL, thus creating
a secure encrypted connection.

10
Figure 17 HTTPS secure connection

Figure 18 HTTP insecure connection

11
1.6 Task 6: Impersonating a Website (Man-in-the-Middle)

Now, we try to impersonate www.uwe.ac.uk. Firstly, we configure our DNS by adding an entry
to the /etc/hosts file using the UWE url (Figure 19). Similar to previous task, we UWE’s
VirtualHost entry to the apache configuration file. Figure 20 shows this the added entry.

Figure 19 Configuring DNS for our hostname

Figure 20 VirtualHost entry

Now we browse our website https://www.uwe.ac.uk and see that we get an error saying that
the connection is not secure. In more details option, we could see the common name of our
UWE url and the certificate does not match, indicating the certificate is not meant for this
domain.

12
 Figure 21 Browsing https://www.uwe.ac.uk

This proves that the MITM attack is defeated in the use of public key infrastructure. If the
common name matched, then the website would have loaded. However, the common name will
match only if the server had a valid certificate from the CA for its domain, which it didn’t, in
this case.
When we try to browse http://www.uwe.ac.uk, the we could see that the page has been
redirected to Apache2 Default page (as shown in Figure 22). Thus, proving MITM attack can
be implemented.

Figure 22 Browsing http:www.uwe.ac.uk

13
1.7 Task 7: Alternative Approaches to (Certificate-Based) PKI (Research
Task)

INTRODUCTION

Public-key infrastructure (PKI) is the basis for using public-key cryptography through key
management. PKI helps in authenticating the public key of the user. If the authenticity is
compromised, any user can use it to decrypt the messages, leading to problem of repudiation.
In certificate-based PKI, a Certification Authority (CA) issues a digital certificate which
authenticates the public key of the user. This digital certificate contains the public key and
identity of the user. If the user wants to use other entities public key, they must verify its
certificate for validating the authenticity of the public key. The major drawback of certificate-
based PKI is scalability and certificate management. (Singh et al., 2019).

HYBRID PKI SCHEMES

To overcome the drawbacks of certificate-based PKI, alternate approaches were proposed.

Identity-based PKI (ID-PKI) was proposed by (Shamir, 1985), which used publicly known
identity (eg. E-mail address) as public-key and the private key is sent to the owner of the
identity (through Email). Although ID-PKI overcome the problem of distributing public key
through certificates, it lacks scalability and support for identity management overhead (Singh
et al., 2019). To overcome the challenges of the certificate-based PKI and IDPKC, the hybrid
approach was introduced which uses the positive features of both these models. In this report,
we will be looking three hybrid PKI approaches:

A) Self- Certificate Scheme:

Lee (Lee and Kim, 2000) proposed this self-certificate scheme which address the issues of
explicit authentication of self-certified key. This self-certificate is user generated for the public
key by signing it with private key to the public key. The key pairs of the users are renewed by
themselves. The authenticity of the Certificate Authority’s certification is maintained without
the user interacting with the CA for renewing the key pairs. The certificate-based scheme’s
revocation method is used by the Certificate Authority to revoke an issued key. The major
advantage of this self-certificate scheme is that the user can renew their key pairs without
interacting with the Certificate authority, meanwhile having the CA’s authentication. The
drawback of this scheme is that it has self-certificate overhead similar to the certificate-based
PKI overhead (Lee and Kim, 2000).

B) Certificate based encryption (CBE) Scheme

Gentry (Gentry, 2003) introduced CBE scheme to provide simple revocation in certificate-
based PKI. By exploiting the pairing, this scheme eases out the certificate management of the
PKI. This scheme implemented the implicit certification from the IBE (identity-based

14
encryption) no escrow from public-key certification, thus producing a hybrid PKI scheme. In
this model, the user generates their own private key or public key pair and request a certificate
from the Certificate authority. For decryption key and proof of certification, the Certificate
authority generates implicit certificate by using IBE scheme. This helps in eliminating the
third-party queries on the certificate status (Gentry, 2003).

Shao (Shao, 2011) propose a new Certificate-Based Encryption scheme from pairings provably
secure in the chosen-key model. This scheme is derived from the CBE scheme of Gentry
(Gentry, 2003), after making some improvements. Each client is allowed to choose its partial
private key and partial public key independently. To deal with the certificate revocation
problem, this paper uses the concept of the time period proposed by Gentry, which is added
into certificate information to eliminate the need of the current certification status. The full
public key of the client is just its certificate information with a time period. As results, anyone
can encrypt messages under the certificate information and the time period so that the receiver
can decrypt only if the receiver’s partial public key is currently certified. However, if a client
entirely trusts the authenticity of a receiver’s partial public key, he could use the partial public
key of the receiver directly to encrypt messages. Furthermore, this high security level is just at
the cost of one more hashing and one more point scalar for encryption, which can be
precomputed once for all. This scheme not only overcomes the weakness in the certified-key
model of the Gentry scheme, but also raises efficiency.

C) Unified Public Key Infrastructure (UPKI) Scheme

Lee (Lee, 2010) introduces a new concept called unified public key infrastructure (UPKI) in
which both certificate-based and ID-based cryptography are provided to users in a highly
combined manner. This scheme assumes the existence of a trusted authority called key
generation and certification authority (KGCA) who has the role of both CA and KGC. It checks
identification information of user and issues a certificate for a user-chosen public key X. It also
issues ID-based partial private key to the user. This paper assumes the existence of multiple
KPAs (Key Privacy Agents) who provide key privacy service. In the proposed private key
issuing protocol user is authenticated with certificate and user's certified public key X is used
to blind the protocol messages such that only the legitimate user can retrieve the ID-based
private key.

CONCLUSION

The demand for successfully implemented PKI systems is increasing as many organisations
are looking to secure their communications. This report provides various hybrid PKI schemes
involving certificates. There is need for some kind of certification is required in order to solve
the problem of explicit authentication and scalability related issues. UPKI achieves all these
problems except with some communication and complexity overhead.

15
1.8 References
Gentry, C. (2003) ‘Certificate-Based Encryption and the Certificate Revocation
Problem’, in Biham, E. (ed.) Advances in Cryptology --- EUROCRYPT 2003.
Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 272–293.
Lee, B. (2010) ‘Unified Public Key Infrastructure Supporting Both Certificate-
Based and ID-Based Cryptography’, in 2010 International Conference on
Availability, Reliability and Security, pp. 54–61. doi: 10.1109/ARES.2010.49.
Lee, B. and Kim, K. (2000) ‘Self-certificate: PKI using self-certified key’, Proc.
of Conference on Information Security and Cryptology, 10(1), pp. 65–73.
Available at: http://cris.joongbu.ac.kr/publication/selfcert-CISC2000.pdf.
Shamir, A. (1985) ‘Identity-Based Cryptosystems and Signature Schemes’, in
Blakley, G. R. and Chaum, D. (eds) Advances in Cryptology. Berlin,
Heidelberg: Springer Berlin Heidelberg, pp. 47–53.
Shao, Z. (2011) ‘Enhanced Certificate-Based Encryption from pairings’,
Computers & Electrical Engineering, 37(2), pp. 136–146. doi:
https://doi.org/10.1016/j.compeleceng.2011.01.007.
Singh, P. et al. (2019) ‘Towards a Hybrid Public Key Infrastructure (PKI): A
Review’, Cryptology ePrint Archive, 509(Report 2019/784), pp. 1–19.
Available at: https://eprint.iacr.org/2019/784.

16