Public-Key Infrastructure (PKI) Lab
web代写 | report | security代做 | 代写Objective | lab代做 | database代写 – 这个题目属于一个web的代写任务, 是比较有代表性的web/report/security/Objective/database等代写方向, 这个项目是lab代写的代写题目
478 - PKI lab 1
Public-Key Infrastructure (PKI) Lab
1 Overview
The learning Objective of this lab is for students to gain some first-hand experience with PKI. By doing
the tasks in this lab, students should be able to gain hands-on experience with public- and private-keys,
digital certificates, Certificate Authorities (CAs) and authentication using PKI.
2 Lab environment.
In this lab, we will use openssl commands and libraries. Pre-built Ubuntu VMs that have openssl pre-installed are available from SEED (https://seedsecuritylabs.org/lab_env.html).
But you can also choose to install OpenSSL and complete the lab directly on your own machine. If you are installing OpenSSL (it is most likely already installed if you are on a Unix like system) the following FREE book is a good resource — https://www.feistyduck.com/library/openssl-cookbook/
Note: that the command and steps in this lab description are assuming a Linux OS (Ubuntu). You may need to modify them according to your machines environment (e.g., OpenSSL version) if you are doing this directly on your machine.
Copyright 2020 Rakesh Bobba, Oregon State University.
Adapted from SEED Labs, Available at https://seedsecuritylabs.org/Labs_16.04/Crypto/Crypto_PKI/
Copyright 2018 Wenliang Du, Syracuse University.
The development of SEED Labs was partially funded by the National Science Foundation under Award No.
1303306 and 1718086. This work is licensed under a Creative Commons Attribution-NonCommercial-
ShareAlike 4.0 International License. A human-readable summary of (and not a substitute for) the license is the
following: You are free to copy and redistribute the material in any medium or format. You must give appropriate
credit. If you remix, transform, or build upon the material, you must distribute your contributions under the same
license as the original. You may not use the material for commercial purposes.
478 – PKI Lab 2
3 Lab Tasks
3.1 [20 pts] Task 1: Becoming a Certificate Authority (CA)
A Certificate Authority (CA) is a trusted entity that issues digital certificates. The digital certificate certi- fies the ownership of a public key by the named subject of the certificate. A number of commercial CAs are treated as root CAs; VeriSign is the largest CA at the time of writing. Users who want to get digital certificates issued by the commercial CAs need to pay those CAs. In this lab, we need to create digital certificates, but we will not use a commercial CA. We will create a root CA ourselves, and then use this CA to issue certificate for others (e.g. servers). In this task, we will generate a certificate for this root CA. Unlike other certificates, which are usually signed by another CA, the root CAs certificates are self-signed. Root CAs certificates are usually pre-loaded into most operating systems, web browsers, and other software that rely on PKI. Root CAs certificates are unconditionally trusted.
The Configuration File openssl.cnf In order to use OpenSSL to create certificates, you have to have a configuration file. The configuration file usually has an extension .cnf. It is used by three OpenSSL commands: ca, req and x509. The manual page of openssl.cnf can be found using Google search. You can also get a copy of the configuration file from /usr/lib/ssl/openssl.cnf. After copying this file into your working directory, you need to create several sub-directories as specified in the configuration file (look at the [CA default] section):
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crls are kept
new_certs_dir. = $dir/newcerts # default place for new certs.
database = $dir/index.txt # database index file.
serial = $dir/serial # The current serial number
For the index.txt file, simply create an empty file. For the serial file, put a single number in string format (e.g. 1000) in the file. Once you have set up the configuration file openssl.cnf, you can create and issue certificates.
Certificate Authority (CA). As we described before, we need to generate a self-signed certificate for our CA. This means that this CA is totally trusted, and its certificate will serve as the root certificate. You can run the following command to generate the self-signed certificate for the CA:
$ openssl req -new – x509 -keyout ca.key -out ca.crt -config openssl.cnf
You will be prompted for information and a password. Do not lose this password, because you will have to type the passphrase each time you want to use this CA to sign certificates for others. You will also be asked to fill in some information, such as the Country Name, Common Name, etc. The output of the command are stored in two files: ca.key and ca.crt. The file ca.key contains the CAs private key, while ca.crt contains the public-key certificate.
3.2 [30 pts] Task 2: Creating a Certificate for OSULabServer.com
Now that we created a root CA, we are ready to sign digital certificates for our customers. Our first customer is a company called OSULabServer.com. There are three steps to getting a digital certificate.
478 - PKI Lab 3
[10 pts] Step 1: Generate public/private key pair. The company needs to first create its own public/private key pair. We can run the following command to generate an RSA key pair (both private and public keys). You will also be required to provide a password to encrypt the private key (using the AES- 128 encryption algorithm, as is specified in the command option). The keys will be stored in the file server.key:
$ openssl genrsa -aes 128 - out server.key 1024
The server.key is an encoded text file (also encrypted), so you will not be able to see the actual
content, such as the modulus, private exponents, etc. To see those, you can run the following command:
$ openssl rsa -in server.key -text
NOTE: We are using AES128 and 1024-bit RSA keys for the lab. However, AES-256 and 2048 bits are
recommended for real production systems.
[10 pts] Step 2: Generate a Certificate Signing Request (CSR). Once the company has the key file, it
must generate a Certificate Signing Request (CSR). The CSR will be sent to the CA, who will generate a
certificate for the key (usually after ensuring that identity information in the CSR matches with the
servers true identity). Please use OSULabServer.com as the common name of the certificate request
when prompted.
$ openssl req - new - key server.key - out server.csr - config openssl.cnf
It should be noted that the above command is quite similar to the one we used in creating the self-signed certificate for the CA. The only difference is the -x509 option. Without it, the command generates a request; with it, the command generates a self-signed certificate.
[10 pts] Step 3: Generating Certificates. The CSR file is transformed into a digital certificate by the CA
through its signature. In the real world, CSR files are usually sent to a trusted CA for their signature. In
this lab, we will use our own trusted CA to generate certificates. The following command turns the certificate
signing request (server.csr) into an X509 certificate (server.crt), using the CAs ca.crt and ca.key:
$ openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key \
- config openssl.cnf
If OpenSSL refuses to generate certificates, it is very likely that the names in your requests do not match with those of CA. The matching rules are specified in the configuration file (look at the [policy match] section). You can change the names of your requests to comply with the policy, or you can change the policy. The configuration file also includes another policy (called policy_anything), which is less restrictive. You can choose that policy by changing the following line:
"policy = policy_match" change to "policy = policy_anything".
Note: In a real CA it is not advised to use policy_anything.
3.3 [50 pts] Task 3: Deploying the Certificate in an HTTPS Web Server
In this lab, we will explore how public-key certificates are used by websites to secure web browsing. We
will set up an HTTPS website using OpenSSLs built-in web server.
[5 pts] Step 1: Configuring DNS. We will use OSULabServer.com as the name of our website. To
get our computers to recognize this domain name, we will need to add the following entry to
/etc/hosts; this entry basically maps the hostname OSULabServer.com to our localhost (i.e.,
127.0.0.1):
127.0.0.1 OSULabServer.com
478 - PKI Lab 4
[10 pts] Step 2: Configuring the web server. Next launch a simple web server with the certificate generated in the previous task. OpenSSL allows us to start a simple web server using the s_server command:
By default, the server will listen on port 4433. You can alter that using the - accept option. You can
access the server using the following URL: https://OSULabServer.com:4433/. Most likely, you
will get an error message from the browser. In Firefox, you will see a message like the following:
OSULabServer.com:4433 uses an invalid security certificate. The certificate is not trusted because
the issuer certificate is unknown.
[10 pts] Step 3: Getting the browser to accept our CA certificate. Had the certificate been signed by a
major commercial CA (e.g., VeriSign), we would not have gotten such an error message, because the CAs
certificate is very likely preloaded into Firefoxs certificate repository already. Unfortunately, the
certificate of OSULabServer.com:4433 is signed by our own CA (i.e., using ca.crt), and this CA
is not recognized by Firefox. There are two ways to get Firefox to accept our CAs self-signed certificate.
- We can request Mozilla to include our CAs certificate in its Firefox software, so everybody using Firefox can recognize our CA. This is how the real CAs, such as VeriSign, get their certificates into Firefox. Unfortunately, our own CA does not have a large enough market for Mozilla to include our certificate, so we will not pursue this direction.
- Load ca.crt into Firefox: We can manually add our CAs certificate to the Firefox browser by clicking the following menu sequence: Edit -> Preference -> Privacy & Security -> View Certificates.
You will see a list of certificates that are already accepted by Firefox. From here, we can import our
own certificate. Please import ca.crt, and select the following option: Trust this CA to identify
web sites. You will see that our CAs certificate is now in Firefoxs list of the accepted certificates.
# Combine the secret key and certificate into one file
% cp server.key server.pem
% cat server.crt >> server.pem
# Launch the web server using server.pem
% openssl s_server -cert server.pem -www
478 – PKI Lab 5
[25 pts] Step 4. Testing our HTTPS website. Now, point the browser again to https:// OSULabServer.com:4433/. Describe and explain your observations. Please also complete the following tasks:
- Modify a single byte of server.pem, and restart the server, and reload the URL. What do you observe? Make sure you restore the original server.pem afterward. Note: the server may not be able to restart if certain places of server.pem is corrupted; in that case, choose another place to modify. A possible option is to delete and insert a byte toward the end of the certificate, but try modifying other parts of server.pem to see what causes issues and what does not. Think about what may happen if you modify the RSA modulus or the private key and then see if your intuition matches up with your observations! (explaining this to yourself may take a bit of extra google work) Think about why certain alterations do not cause issues while others do.
- Since OSULabServer.com points to the localhost, if we use https://localhost: instead, we will be connecting to the same web server. Please do so. Describe and explain your observations.
4 Submission
You need to submit a detailed lab report in PDF format describing what you have done and what you have observed; you also need to provide explanation to the observations that are interesting or surprising. In particular, you report must include the following:
- Screenshots of browser access to https://OSULabServer.com:4433/ before and after adding the CA certificate to Firefoxs certificate repository.
- Explanations for what is observed in each screenshot and why they are different.
- The effect of modifying a byte in server.pem and an explanation for what you observed.
- The effect of browsing to https://localhost:4433 and an explanation for what you observed.
- Descriptions of any obstacles encountered and their solutions.
- Descriptions of any interesting or surprising observations and explanations of those observations.
You must also submit a ZIP file containing the keys and certificate files you produced as well as a text README. Specifically, the zip file must include:
- CA key and certificate ca.key, ca.crt.
- Server key, csr, certificate, and pem file server.key,server.csr,server.crt,server.pem.
- README file containing the passwords for the CA and server keys.