SecureApps. X.509 Certificates: A Tutorial for ios. Jorn Lapon MSEC Research Group Dept. of Computer Science KU Leuven, TCG

Transcription

1 SecureApps X.509 Certificates: A Tutorial for ios Jorn Lapon MSEC Research Group Dept. of Computer Science KU Leuven, TCG

2 Contents 1 Introduction 4 2 Theory on Public Key Infrastructures Building-Blocks Symmetric-Key Cryptography Public-Key Cryptography The PKI ecosystem Parties Actions Public-Key Certificates General Creating Certificates Certificate Revocation Certificate Validation File Formats General approach and Set-up Prerequisites & Tutorial approach A Custom PKI Infrastructure Setup a Standard Web Server The ios Project Server authentication Setup CA hierarchy and generate client certificates Setup folders Create CA certificates Create SSL Server Certificate Setup a Secure Site on Apache Page 2 of 41

3 4.3 Server Authentication on ios Built-in Applications Accessing the server from a custom app Client/Mutual Authentication Creating Client Certificates Enabling Client Authentication on the web server Client Authentication on ios Built-in Applications Enabling Client Authentication in a Custom App A Build & Setup Environments 40 A.1 Server Environment A.2 Mobile Environment B Sources 41 C FAQ 41 Page 3 of 41

4 1 Introduction This tutorial covers the basic steps towards the use of X.509 certificates for strong authentication in Mobile Environments (Android and ios). Knowledge on the use of X.509 certificates in general and platform specific, is presented for application developers. In short this tutorial learns the reader the following: Setup a custom X.509 PKI using OpenSSL. Setup an Apache 2 Web Server Configure the web server to support SSL server authentication (i.e., Https) using a custom server certificate. Configure the web server to support SSL client authentication. Import root and identity certificates in the device Keychain of the mobile device for use in standard applications (e.g., the browser). Setup an Https connection with the server from within a custom app on the mobile with server authentication. Setup an Https connection with the server from within a custom app on the mobile with client authentication. The files accompanying this tutorial can be downloaded from X509_Tutorial. First, we start with some theory on X.509 and PKI in Section 2, in which the main concepts and building blocks are discussed. In Section 3, we demonstrate step-by-step, how to setup and implement X.509 certificates. We, therefore, show how to generate a custom PKI, initialize a web server that uses this PKI and show how to support both server and client authentication on ios. Page 4 of 41

5 2 Theory on Public Key Infrastructures In this section, cryptographic building blocks are introduced that are important when applying X.509 certificates. We start with symmetric and public-key cryptography, followed by its use in certificates and the PKI eco-system. 2.1 Building-Blocks Symmetric-Key Cryptography Symmetric-Key cryptography, also called conventional or secret-key cryptography, is based on a secret key (Key) that is shared among the parties that want to exchange confidential data. The same key is used both for encryption and decryption. Ciphertext encrypt(key, P laintext) The encrypt-operation converts Plaintext into Ciphertext using the secret key Key. Plaintext decrypt(key, Ciphertext) The decrypt-operation converts Ciphertext into Plaintext using the secret key Key. Key Key m c c m Dear Bob, encrypt Xqs987f2sdlkc2 Xqs987f2sdlkc2 decrypt Dear Bob, Figure 1: Alice sending a message to Bob using symmetric cryptography Examples of symmetric-key encryption schemes are: Twofish, Serpent, AES (Rijndael) and Blowfish. Every encryption scheme can be turned into a probabilistic encryption scheme by adding random data to the plain text. This way, different encryptions of the same plain text (with the same key) will yield a different cipher text. Hence, a passive attacker cannot link both cipher texts. When the cipher text is decrypted, the random value is discarded. Ciphertext encrypt(key, {Random P laintext}) Before encrypting the plain text, a random value is generated and concatenated with the plain text. (Random P laintext) decrypt(key, Ciphertext) The decryption of the cipher text yields both a random value and the plain text; the random value is discarded Public-Key Cryptography Before symmetric encryption can take place, the secret must be shared securely, which is not evident when the corresponding parties never met before. Public-Key cryptography tackles this problem: Page 5 of 41

6 In public-key encryption schemes, each entity has a Public Key (pk) and a corresponding Private Key (sk). The Public Key is public and can be shared with anyone. A message encrypted with this Public Key can only be decrypted by the owner of the corresponding Private Key. Two operations are defined: Ciphertext encrypt(pk, P laintext) The encrypt-operation converts Plaintext into Ciphertext using the public key pk. P laintext decrypt(sk, Ciphertext) The decrypt-operation converts Ciphertext into Plaintext using the private key sk. pk Bob sk Bob m c c m Dear Bob, encrypt Xqs987f2sdlkc2 Xqs987f2sdlkc2 decrypt Dear Bob, Figure 2: Alice sending a message to Bob using asymmetric cryptography Examples of public-key encryption schemes are: RSA, Rabin and ElGamal. As shown in Fig. 2, Alice wishing to send a message m to Bob, first obtains an authentic copy of Bob s public key (pk Bob ), uses the encryption algorithm to compute the cipher text c = encrypt(pk Bob, m) and transmits c to Bob. To decrypt c, Bob takes his private key sk Bob and applies the decryption algorithm to obtain the original message m = decrypt(sk Bob, c). The public key need not to be kept secret and, in fact, should be made public. Only its authenticity is required to guarantee that Bob is the only party who knows the corresponding private key. A primary advantage of such systems is that providing authentic public keys is in general easier to realize than distributing secret keys securely (as required in symmetric-key systems). In a large-scale networked environment, it is impossible to guarantee that prior relationships between communicating entities have been established or that a trusted repository exists with all used public keys. Therefore, certificates [4] will establish the authentic binding between public key and owner of the corresponding private key (cfr. Sect. 2.3). Digital Signature. Some public-key encryption schemes also allow for digitally signing data. Similar to public-key encryption, only the owner of the private key is able to create a genuine signature, and everyone may verify the correctness using the public key. In this case, two more operations are defined: Sig sign(p rivatekey, Data) The sign-operation generates a signature Sig on message Data using the private key PrivateKey. SigOK verify(p ublickey, Sig, Data) The verify-operation verifies whether the signature Sig on Data is genuine. The verification uses the public key PublicKey that corresponds to the private key with which the signature was generated. Page 6 of 41

7 2.2 The PKI ecosystem Parties In the PKI ecosystem, we can distinguish 4 different types of actors. Certificate Authority. The entities issuing certificates are called Certificate Authorities (CAs) or simply issuers. A CA that issued a certificate to itself (self-signed) is called a Root CA. It can issue certificates to end entities (e.g., client certificates or server certificates) or to other CAs called Intermediate CAs. Certificate Holder. A Certificate Holder or Subscriber may be any party that holds the private key corresponding to the public key certified by a CA. In fact, a root authority that issues a self-signed certificate, is also a Certificate Holder. Relying Party or Verifier. When the certificate is used to authenticate, the party to whom the certificate holder is authenticating is called the Relaying Party. This party verifies that the authentication is performed correctly, and that the certificate is still valid. Revocation Authority. When, for instance, a private key got compromised or the certificate content is no longer valid, it is important to have a way to make the public aware that a certificate is no longer valid. This is called certificate revocation. The entity that handles the certificate revocation is called the Revocation Authority Actions Certificates are most commonly used in applications either for encryption, for digital signatures, or secure communication. Encryption. Any party that received the public certificate can encrypt data. Only the certificate holder, holding the corresponding private key is able to decrypt the data. Digital Signatures and Authentication. Digital signatures are used for two reasons. The first is the digital version of the physical signing of documents. Only the certificate holder can make a valid signature that can be verified with the corresponding certificate. The second reason is for authentication. In fact, authentication consists of making a digital signature on a challenge received from a relying party. If the entity that wants to authenticate, is able to make a valid signature on that challenge, this means that this party is indeed the entity specified in the certificate (unless the private key or CA was compromised). Secure Communication. Setting up a secure communication channel using certificates is standardized in the SSL/TLS protocol In SSL/TLS, the certificates are used both for authentication and for encryption. Page 7 of 41

8 To secure communication with web sites and services, the Http protocol is replaced by the Https protocol. Https is a combination of the standard Http protocol and SSL/TLS In this case, there are two options: Server Authentication in which the server authenticates towards the client. Client Authentication in which the client authenticates towards the server. However, in Https client authentication is only used in combination with server authentication. This is also called mutual authentication. 2.3 Public-Key Certificates General Although public key cryptography solves the problem of sharing a secret (now, only the public part must be shared), a relying party does not know to whom the public key belongs. One solution is to use digital certificates. In short, a certificate is a statement of a third party, claiming that the owner of the private key corresponding the public key in the certificate holds the attributes in the certificate. It is up to the relying party to trust if the third party verified this correctly. The trusted third party, called a Certification Authority (CA), vouches for the correctness of the information in the certificate. A digital certificate is a digitally signed statement that binds a public key held by an entity (such as a person, an organization, an account, a device, or a site) to a set of information (e.g., name, address, account number, web address) that identifies the holder of the corresponding private key. Figure 3 shows a user (Bob) authenticating using his certificate, issued by CA, towards a relying party. In order to authenticate, the relying party sends a random challenge which Bob signs using his private key. The resulting signature is sent to the relying party which can now verify that the signature indeed corresponds to the public key contained in the certificate. In addition, the relying party must verify the certificate. Among others, it checks that the certificate is not expired (i.e., datef rom < NOW < dateuntil) and that the certificate was created by trusted CA. The relying party, therefore, fetches the public key of the issuing CA from his list of trusted CA s and verifies that the signature of the issuer is valid. If this signature is invalid, or the public key was not found in the list of trusted CA s, the relying party does not trust the authentication. issues CA trusts Bob Bob challenge Bob Relying Party + sign(challenge, ) Figure 3: Bob holds a certificate issued by CA and used to authenticate to a relying party. Page 8 of 41

9 In practice, the most commonly used CA certificates are included (built-in) in operating systems and browsers as trusted root certificates. Some examples of CA s are the public Certification Authorities, such as Global- Sign, VeriSign, Thawte, Entrust and Diginotar 1. Note that organizations can also create their own Certificate Authority. To list the public keys of trusted parties, each CA publishes a self-signed certificate (i.e., subject and issuer are the same), containing the public key that can be used to verify the certificates it issued. X.509 Certificates. The most well-known public-key certificates are X.509 certificates [4, 3]. The standard was defined in 1988, modified in 1993 (Version 2) and extended in 1995 (Version 3). Standard extensions for Version 3 certificates appear in an amendment to X.509. These certificates accommodate information related to key identifiers, key usage, certificate policy, alternate names (versus X.500 names) and name attributes, certification path constraints, and enhancements for certificate revocation including revocation reasons and CRL partitioning. A typical X.509 certificate has the following structure: Version Serial Number Algorithm ID Issuer Validity Not Before Not After Subject Subject Public Key Info Public Key Algorithm Subject Public Key Issuer Unique Identifier (Optional) Subject Unique Identifier (Optional) Extensions (Optional)... Certificate Signature Algorithm Certificate Signature Table 1: Structure of a typical X.509 Certificate An example X.509 certificate is shown in figure 4. 1 Diginotar is no longer trusted after it was hacked: Page 9 of 41

10 Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256withrsaencryption Issuer: C=BE, ST=East Flanders, L=Ghent, O=KU Leuven - Campus Ghent, O=Computer Science Department, OU=MSEC, CN=MSEC Tutorial Client CA Validity Not Before: May 12 13:38: GMT Not After : May 12 13:38: GMT Subject: C=BE, ST=East Flanders, L=Ghent, O=KU Leuven - Campus Ghent, O=Computer Science Department, OU=MSEC, CN=Alice in Wonderland / address=alice@msec.be Subject Public Key Info: Public Key Algorithm: rsaencryption Public-Key: (2048 bit) Modulus: 00:be:2e:3d:32:72:4a:92:ff:67:7b:df:7c:89:83:... 72:91 Exponent: (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 5D:1D:32:41:95:72:C6:CA:9C:E6:91:4B:32:50:C7:6E:14:68:F9:CA X509v3 Authority Key Identifier: keyid:8b:d5:5e:f2:84:62:04:e4:91:25:78:74:87:14:5f:f2:f0:20:ac:2e DirName:/CN=MSEC Tutorial Root CA/OU=MSEC/O=KU Leuven - Campus Ghent/ O=Computer Science Department/L=Ghent/ST=East Flanders/C=BE serial:02 X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication Signature Algorithm: sha256withrsaencryption 3e:be:89:73:ed:92:ff:f2:89:2b:98:0a:46:e8:26:b7:af:53:... a7:4a:ec:89 Figure 4: Example of an X.509 certificate CA hierarchy. The example above presents a single CA issuing certificates to users. But other more complex settings are also possible. For instance, a root certificate authority can delegate the issuance of certificates to Intermediate Authorities. Resulting in, for instance, a two level hierarchical CA, in which the root is a company wide CA, and the second level contains departmental CA s issuing certificates to users. Note that the more levels in the CA structure, the more trust is needed in the authorities. For instance, Page 10 of 41

11 Diginotar, a public CA, went bankrupt after it was discovered that their private key got compromised. The degree to which a relying party can trust the binding embodied in a certificate depends on several factors. These factors can include: the practices followed by the certification authority (CA) in verifying the subject; the CA s operating policy, procedures, and security controls; the scope of the subscriber s responsibilities (for example, in protecting the private key); the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability). The certificate may contain a field declaring that one or more specific certificate policies [5] apply to that certificate. The policy may be used by a relying party to help in deciding whether a certificate, and the binding therein, are sufficiently trustworthy and otherwise appropriate for a particular application. Use of Digital Certificates. Examples of use cases in which digital certificates are used, are digitally signed or electronic documents, and Secure Web sites (Https). Note that in the case of Secure Web Sites, the website is the certificate holder and the browser/user is the relying party. Secure websites use digital certificates to authenticate towards the user, and encrypt the communication with the site. The browser, therefore, verifies that the web address contained in the certificate used to setup a secure communication, corresponds to the address (e.g., URL) of the website being accessed. In other words, (as shown in Fig. 5) the browser verifies that the certificate was issued by a certificate authority listed in the trusted certificate authorities (1) and the certificate contains the web address specified in the browser (2). Figure 5: SSL Server Certificate Page 11 of 41

12 2.3.2 Creating Certificates In order to obtain a certificate, a user first creates a certificate signing request (CSR) and sends it to the CA and finally retrieves the signed certificate from the authority. Creating a Certificate Signing Request. A certificate signing request [7] is a digitally signed request to obtain a certificate containing specific attributes. Therefore, the applicant typically generates a key pair of which the private key is kept secret and used to sign (identifying) information including the newly generated public key. Information typically included in the request are the distinguished name, Organization, Department, City, Region, Country and/or Address. Finally, this request is submitted to the certificate authority. Signing a Certificate Signing Request. The certificate authority verifies the CSR. The signature is verified, ensuring that the applicant holds the private key corresponding to the public key in the CSR. The authority is also trusted to verify that the attributes to be included in the certificate are genuine. It can do so by verifying other credentials or proofs of identity sent with the request, or by contacting the applicant for further information. Finally, if all information is valid, this information (possibly joined with information included by the authority) is certified by by the authority. The resulting certificate is returned to the applicant. Self-signed Certificate. Instead of including the public keys of root authorities in the list of trusted parties (e.g. in the browser), root authorities create a self-signed certificate. In this case, the creator is also the holder of the certificate. The issuer and subject of such certificates are the same. The signature is created using the private key corresponding to the public key contained in the certificate, hence, self-signed Certificate Revocation The validity dates (i.e., valid from, valid until) contained in the certificate are not sufficient to verify that a certificate is still valid. Next to this time limitation, other reasons may require to revoke a certificate. The revocation reasons defined in RFC 3280 are: revoked: A certificate is irreversibly revoked (and entered on a CRL) if, for instance, it is discovered that the certificate authority (CA) had improperly issued a certificate or a privatekey is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements such as publication of false documents, misrepresentation of software behaviour, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user s not being in sole possession of the private key (e.g token containing the private key has been lost or stolen). hold/supended: This reversible status can be used to notice the temporary invalidity of the certificate, for instance when the user is not sure if the private key has been lost. If, in this example, the private key was found again and nobody had access to it, the status can be reinstated, and the certificate is valid again, thus removing the certificate from further CRLs. Certificates in the Belgian e-id card are initially set to the suspended-status, until the card has been issued to and activated by the card holder. Page 12 of 41

13 One solution is to (white)list the serials of valid certificates, and check this upon authentication. This solution is, for instance, used in Microsoft IIS7 when mapping certificates to users in an LDAP database. Another solution is slightly more complex and uses certificate revocation lists (CRL) [3]. A CRL is a (black)list of certificates (more accurately: their serial numbers) which are currently not valid (revoked or suspended), and should not be relied on by any system entity. Usually, a CRL is generated after a clearly defined time frame and (optionally) immediately after a certificate has been revoked. The CRL is always issued by the CA that issued the corresponding certificates. All CRLs have a (often short) lifetime in which they are valid and in which they may be consulted by a PKI-enabled application to verify a counterpart s certificate prior to its use. To prevent spoofing or denial-of-service attacks, CRLs are usually signed by the issuing CA. Best practices require that a certificate s validity must be checked whenever one wants to rely on that certificate. Otherwise, a revoked certificate may be incorrectly accepted as valid. This means that to use a PKI effectively one must have access to current CRLs (i.e. Internet access in the case of a PKI). An alternative to using CRLs, which is especially useful for software clients, is the on-line certificate validation protocol Online Certificate Status Protocol (OCSP) [2]. OCSP has the primary benefit of requiring less network bandwidth and thus enabling real-time and near real-time status checks for high volume or high value operations. It is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC Compared to CRLs, OCSP has the following advantages and disadvantages: Since an OCSP response contains less information than a typical CRL, OCSP can feasibly provide more timely information regarding the revocation status of a certificate without burdening the network. However, the greater number of requests and connection overhead may overwhelm this benefit if the client does not cache responses. Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. However, this is balanced by the practical need to maintain a cache. In practice, such considerations are of little consequence, since most applications rely on third-party libraries for all X.509 functions. CRLs may be seen as analogous to a credit card company s bad customer list an unnecessary public exposure. OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so this information may also be intercepted by other parties Certificate Validation When verifying a digital signature, not only the validity of the signature is important, but also the validity of the corresponding certificate and its entire certificate chain. The steps to verify a digital signature (both for signing documents or during authentication) can be summarized as follows: 1. Verify the signature with the public key in the certificate 2. Verify the issuer signature of the certificate. Page 13 of 41

14 3. Verify the validity date of the certificate. 4. Check that the certificate was not revoked. 5. Verify the validity of the issuing certificates in the certificate chain (i.e., check issuer signature, validity date and revocation status). 6. Verify that the root CA or an intermediate CA is trusted File Formats Certificate Format. The most common formats of certificate are the following: ASN.1 DER-encoded format (binary BER-encoded) PEM (BASE64 encoded) BEGIN CERTIFICATE----- Listing 1: Excerpt of a PEM encoded certificate 2 MIIFJDCCBAygAwIBAgIBATANBgkqhkiG9w0BAQsFADCBrzELMAkGA1UEBhMCQkUx 3 FjAUBgNVBAgTDUVhc3QgRmxhbmRlcnMxDjAMBgNVBAcTBUdoZW50MSEwHwYDVQQK 4 ExhLVSBMZXV2ZW4gLSBDYW1wdXMgR2hlbnQxJDAiBgNVBAoTG0NvbXB1dGVyIFNj uwnsnqe2d2qkb0feta2csvojojg7n0wzkokgfierz9l1zabnjg51vdwrpsfikxnd 7 +1KlTjs++EvvKZsVgogLjcP/m5rRHqnwnxhzJTQeUXvq2oCQXUHzkoRnxAibT1w3 8 shr72y7rxvkgmtjluqrygdcijcfeukmg END CERTIFICATE----- XML Key Store File Formats The most common key store file formats are the following: PEM (*.pem, *.crt, *.cer) Governed by RFCs, it s used preferentially by open-source software. Next to storing certificates (see above), this format also allows to store private keys and entire certificate chains. PKCS12 (*.pkcs12, *.pfx, *.p12) A private standard that provides enhanced security versus the plain-text PEM format. Unlike the PEM format, the content is fully encrypted. It s used preferentially by Windows systems, and can be freely converted to PEM format through use of OpenSSL. Jave Key Store (*.jks) When using Key Stores in Java, the Java Key Store is used in general. In other environemnts, JKS files are often not supported. Bouncy Castle Key Store (*.bks) This format is the main format to be used in Android. For instance, although other formats are supported, it is the only format that can be used to import certificates in the Android KeyChain. For converting key stores from one format to another, Protecle can be used. Page 14 of 41

15 3 General approach and Set-up 3.1 Prerequisites & Tutorial approach Environments. The systems used to run the tutorial are as follows: Web Server The server will be deployed on Linux Mint 16 Petra Cinnamon. See Appendix A.1 contains the steps to prepare the Linux environment for this tutorial. ios App The ios App is built using XCode on a MacBook running XCode (Version 5.1.1). The target platform of the project is iphone 7.1. The tutorial files. All tutorial files are packed together and can be downloaded from: The package contains 2 folders and the tutorial text. Tutorial X509 ios contains the XCode tutorial project for the ios App. Tutorial X509 Server contains the files to setup the server. It consists of seven scripts (.sh files) and a config folder containing additional configuration and build files. For the seminar the server files are already pre-installed on a workstation and can be found on the Desktop. For the ios app, donwload and unzip the Tutorial X509 ios.zip file and open the project in XCode. The tutorial was tested with an emulator for iphone 7.1. Notes about the Tutorial Scripts: Not all commands in the scripts are described in this tutorial. Comments are added to the scripts and additional checks are used to ensure the correct working of the tutorial. To make sure the tutorial runs correctly, configuration files and commands are specified such that the user has to enter as little as possible. For instance, passwords are fixed in the scripts (i.e., passed by passout= pass:mypassword) and users are not prompted (i.e., prompt = no in the OpenSSL config file) to change the value of the attributes in certificates. The Tutorial outline. marked as follows: To lead the reader through the tutorial, special information and instructions are Page 15 of 41

16 Viewing or analyzing a file or content goes here. Actions that need to be performed on the device (mobile or desktop) are presented here. Commands that need to be run in a console are presented here. Remarks are shown here. Additional information is shown here. Running scripts on the server. To run a script on Linux Mint, open a terminal (click in the menu bar) and type the following to run the file script.sh 1 $./script.sh Some scripts require higher privileges and require commands to be run as root. On Linux Mint 2 you can do this using the sudo command. In this case, during the execution of the script, you will be requested to enter the password for the root user. The root password used on the workstation for this tutorial is: msec Important: During this tutorial except for running the scripts, no commands have to be entered in the console. All instructions are given in the Action, View and Console boxes. Other code and commands in the text are purely for your information. 3.2 A Custom PKI Infrastructure This tutorial learns the reader, step-by-step, how to create a custom PKI infrastructure and use it in mobile environments (ios and Android) A simple web server (i.e., Apache 2) is installed and configured to support 2 Note that Linux Mint is based on Ubuntu, and the scripts used in this tutorial work for both Page 16 of 41

17 both server and client authentication. In order to take advantage of both mechanisms in mobile environments, this tutorial shows how to add support in both ios and Android when using the built-in browser and also when writing a custom App. The tutorial starts from a clean standard Linux Mint Desktop installation and uses scripts to create the PKI and install the web server. Nevertheless, some pointers will be given to enable the same on Microsoft IIS. For both ios and Android, a project has been created (with XCode and Eclipse, resp.) that shows the user how to enable certificate support in their custom Apps. A certificate issued by a public certificate authority such as GlobalSign or Verisign, is required when used in a public website or other applications that use the built-in trust store. This prevents the user having to install your root certificate manually. Nevertheless, in many applications it is sufficient to set-up a custom PKI. This tutorial learns the reader step-by-step how to create such a custom infrastructure and how to implement it on both server and client side. For this tutorial, a two level hierarchical CA structure is generated as shown in Figure 6. The root authority (MSEC Tutorial Root CA) issues a certificate to a CA (MSEC Tutorial Server CA) that issues server certificates and a certificate to a CA (MSEC Tutorial Client CA) that issues client certificates. To request, issue and manage certificates the command-line tools provided by the OpenSSL [6] package are used. MSEC Tutorial Root CA MSEC Tutorial Server CA MSEC Tutorial Client CA MSEC Tutorial SSL Server Alice in Wonderland Bob The Builder Figure 6: A Custom X.509 PKI 3.3 Setup a Standard Web Server For this tutorial, the scripts to setup the web server are placed on the desktop in the folder Tutorial X509 Server. Page 17 of 41

18 Open a terminal (i.e., Click in the menu bar at the bottom of your screen). Go to the folder containing the tutorial files: 1 $ cd Desktop/Tutorial_X509_Server To ease the typing of commands in the terminal, you can start typing the first letters of a file or folder and press TAB to get the full list of possible files and folders in the folder specified. From now on, all folders are specified relative to this Tutorial X509 Server folder unless specified differently. The scripts in this tutorial assume a fresh install of Linux Mint. Do not use these scripts on an existing system as files may be deleted from your system! Setup Apache and PHP5 on Linux Mint The Apache HTTP Server Project?? is an effort to develop and maintain an open-source HTTP server for modern operating systems. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. PHP is a server-side scripting language that will be used to present a web page with some information about the connection. For details on both Apache and PHP we refer to the original websites and many tutorials available. In this tutorial we focus on the configuration of Apache to enable HTTPS with server and client authentication. In order to install Apache and PHP5 the package management tool APT is used. This is an efficient way to install packages and dependencies automatically and take care of their configuration. To enable php5 in apache2 the a2enmod command is used. 1 $ sudo apt-get install apache2 php5 2 $ a2enmod php5 Apache is able to serve multiple sites, called Virtual Hosts. A default Virtual Host (located at /etc/apache2/sitesenabled/000-default.conf) is configured to handle Http requests on port 80, the standard Http port, and serves web pages from the directory /var/www. For more in-depth documentation on configuring the Apache Http Server we refer to By default, a file index.html is generated in the /var/www folder. The tutorial script will remove this file and replace it with index.php which will be automatically assigned as the default web page. Page 18 of 41

19 Run the first script of the tutorial, enter the root password when needed and confirm installation (i.e., Y ). 1 $./Tutorial_0_Apache_Install_Apache.sh Write down the IP Address that is returned after running the script. Open a browser and go to You should see something like this: 3.4 The ios Project. In order to develop an ios application, an XCode project has been created (it is part of the tutorial package, available for download). Page 19 of 41

20 Open XCode and explore the X509 Tutorial ios project. In the X509 Tutorial ios sub-folder, you will find the source code for the project. The most important files that will be used in this tutorial are the MainUIViewController.h header and MainUIViewController.m class file. Open both classes and have a look inside. Run the project by clicking the arrow button ( ). This will build the ios app, launch the emulator (if not launched before) and run the application. The emulator will start and show you the start screen of the Android App. Do not close the emulator! Starting the emulator takes a long time. However, this is required only once. The emulator can be kept running and when starting the app again from the XCode environment, XCode detects that the emulator is running and automatically closes the app inside the emulator (if it is still running), deploys the new version of the app and starts it for you. Page 20 of 41

21 The emulator shows the MainUIViewController. There is only one UIViewController in the project. For this tutorial, the MainUIViewController was prepared with a number of controls. It contains a switch that allows the user to select Insecure and Secure. In the white area, a UIWebView control is included that will show the results of the HTML pages fetched from the server. Depending on the switch, the button makes a connection with the server either securely over Https or insecurely over Http. However, before doing this, we have to let the app know the IP address of our web server. In Xcode, open the MainUIViewController.m file and locate the following line of code Replace by the IP address that you got previously a. You should get something like this, with your IP Address instead: a You can fetch the IP address with the config/get IPAddress.sh script Setting up a connection in XCode is simple. During this tutorial, we will use the NSURLConnection to make connections to our web server. Using the NSURLConnection class, setting up a connection can be achieved as follows: 1 NSString *url = [NSURL 2 3 NSURLRequest *request = [NSURLRequest requestwithurl:url]; 4 5 NSURLConnection *conn = [[NSURLConnection alloc]initwithrequest:request delegate: self]; This can be found in the -(IBAction)btnConnect:(id)sender method, in the MainUIViewController.m class file. As can be seen in this listing, in the tutorial app, we pass self (in other words the MainUIView- Controller) as a delegate to the NSURLConnection. Therefore, we add NSURLConnectionDelegate in the MainUIViewController.h header file to indicate that this class implements this delegate. Page 21 of 41

22 Start the ios Application, and click the search button. The app will connect to your server and you should see the following: 4 Server authentication 4.1 Setup CA hierarchy and generate client certificates Setup folders. During this step, several certificates, keys, etc., will be created for different entities. To organize things, we start with creating a number of folders and files required to request and issue certificates. 1 $./Tutorial_1_PKI_setupDirectories.sh This script creates a directory build, containing five subdirectories: three for each CA, one for the clients (clientcert) and one for the server (servercert). For each CA, a subdirectory ca.db.certs is generated where all issued certificates will be stored, an empty index file ca.db.index, a serial file ca.db.serial containing 01 as the initial serial number and a seed for the randomness is stored in ca.db.rand. Open the build folder (Double-Click the folder on the Desktop) and view its contents Create CA certificates. The next step in creating the CA Structure is to setup the CA s. To create the certificates for the root CA and both the Server and Client CA, the commands are all contained in the Tutorial 2 PKI Create CAs.sh script. Page 22 of 41

23 Open and analyze the script Tutorial 2 PKI Create CAs.sh. In this script, a number of configuration files (*.cnf) located in the config folder, is used by OpenSSL. The files starting with req are configuration files used by applicants to create a certificate request. The files starting with issue are used by the respective CAs to generate a certificate. Finally, the file self rootca.cnf configures both request and issuance of a self-signed certificate for the root authority. Note that for this tutorial, all commands are included in the same script, but in practice they will be performed by each entity and the requests and certificates will be communicated between the applicant and the issuing authority. We will now go over the most important commands in the script. MSEC Tutorial Root CA. To create a self-signed CA certificate the following command is used: 1 $ openssl req -x509 -config config/self\_rootca.cnf -newkey rsa -keyout build/rootca/ rootca.key -out build/rootca/rootca.pem -passout pass:rootca This command internally creates a certificate signing request containing the values specified in the req section of the config file (-config config/self rootca.cnf). It, therefore, generates a new rsa keypair (-newkey rsa -keyout build/rootca/rootca.key) protected with the password rootca and outputs the certificate in PEM format(-out build/rootca/rootca.pem) containing the public key. Open and analyze the root authority configuration file config/self rootca.cnf (Double- Click the file in the file explorer). The configuration file contains multiple sections. [ca] is simply a section that refers to the default ca section, namely [CA default]. In this section, the location of the files created previously for the root authority are specified, together with some defaults, for instance, for the name of the certificate and key of the root CA, and the hashing algorithm used. The section [req] defines the content of the attributes that must be specified in the request. Amongst others, it refers to the value of the subject s name ([req distinguished name]), but also the extensions of the certificate. In order to allow a certificate to be used by a Certificate Authority, the following (Version 3) extension must be part of the certificate: 1 basicconstraints = CA:true MSEC Tutorial Server and Client CA. but are generated in three steps: The remaining certificates in the hierarchy are not self-signed, 1. The applicant generates a certificate signing request (CSR) and sends it to the signing authority. Page 23 of 41

24 2. This authority verifies and validates the request, issues a certificate based on the request and returns it to the applicant. 3. The applicant verifies and stores the returned certificate. In order for the Server CA to generate a CSR, the following command is executed; doing this for the Client CA is analogous. 1 $ openssl req -config config/req_serverca.cnf -newkey rsa -keyout build/serverca/ serverca.key -out build/serverca/serverca.req -passout pass:serverca The main difference with the command to issue a self-signed certificate is the -x509 argument which is now omitted. This tells OpenSSL to generate a CSR instead of a self-signed certificate. Open and analyze the configuration file of the Server CA to request a certificate config/req serverca.cnf (Double-Click the file in the file explorer). In contrast to the previous configuration file, this file does not contain a [ca] section. Now, the [req] section specifies the content of the CSR to be created. Note that the basicconstraints extension specified in the config file adds an additional parameter, pathlen:0. This indicates that the intermediate authorities cannot issue sub-ca certificates. Except for the name of the subject in the request, the configuration file of the Client CA is the same as the one of the Server CA. In practice, one may add additional attributes, such as a policy that specifies the CA s practices or other information. After generating the request, the requesting CA sends it to the issuing CA to obtain a certificate. The following listing shows the command that the root authority performs to issue a certificate to the Server CA. 1 $ openssl ca -notext -batch -passin pass:rootca -config config/issue_by_rootca.cnf - out build/serverca/serverca.pem -infiles build/serverca/serverca.req This command generates a certificate and specifies the configuration file, the output file, the request file and the password of the root CA. (The -batch argument is passed for this tutorial, preventing the user to have to confirm each transaction during the generation of the certificate.) The -notext argument is passed to ensure that the PEM file does not include a textual representation of the certificate, since some platforms have difficulties reading the file in that case. Note that the private key used for signing the certificate is specified in the configuration file (issue by rootca.cnf). Key Stores. To import the certificate of the root authority into Android, one solution is to use a Bouncy Castle KeyStore. The certificate is imported using the keytool into a Bouncy Castle KeyStore: 1 $ keytool -importcert -alias ssl_ca -trustcacerts -keystore build/servercert/ SSL_Server_chain.bks -storetype bks -storepass userpwd -file build/rootca/rootca. pem -noprompt -provider org.bouncycastle.jce.provider.bouncycastleprovider - providerpath config/bcprov-jdk15on-146.jar Page 24 of 41

25 This command generates a BKS keystore file (SSL Server chain.bks) and imports the rootca.pem file as a trusted CA certificate with alias ssl ca. To generate BKS files, the keytool requires BouncyCastleProvider to be specified explicitly. Likewise, a certificate chain is required to be used by the SSL enabled web server. Generating a certificate chain in PEM format is straightforward and is simply a concatenation of the certificate files: 1 $ cat build/serverca/serverca.pem build/rootca/rootca.pem > build/servercert/ SSL_Server_chain.pem Time for Action. Create the CA certificates by running the following script: 1 $./Tutorial_2_PKI_Create_CAs.sh Have a look at the files created in the sub folders of the build folder. To read out the contents of a PEM file, the following command can be used: 1 $ openssl x509 -in cert.pem -text Analyze and compare the contents of the PEM certificate of the root and server CA: 1 $ openssl x509 -in build/rootca/rootca.pem -text 2 $ openssl x509 -in build/serverca/serverca.pem -text Notice that for the former, issuer and subject are equal, while in the latter, the issuer is the root CA. Also the basicconstraints extension is different Create SSL Server Certificate To obtain an SSL Server Certificate, a CSR is generated on the web server and the Server CA generates a certificate that is returned to the server. The Tutorial 3 PKI Create SSL ServerCert.sh script generates the CSR, and issues a certificate based on this CSR. Page 25 of 41

26 Open the Tutorial 3 PKI Create SSL ServerCert.sh script. Notice that instead of passing a password, the -nodes parameter is specified. This specifies that the private key generated during the request is not encrypted with a password. This is done such that the web server does not need a password to use the key for SSL Server authentication in Apache. The script also contains code (in comments) to export the private key and certificate to a PKCS#12 keystore file. This can, for instance, be used to install the key on a Microsoft IIS web server. Open the config/req servercert.cnf. Notice that the extendedkeyusage field is set to serverauth to allow the certificate to be used for SSL server authentication Also, an extra field is added to the request, namely the subjectaltname. For this tutorial, it contains an IP sub-field with the IP address, and a DNS sub-field also containing the DNS address. Among others, this is required by the mobile to allow a correct host name verification. In practice, the actual DNS domain name should be included in this field (e.g., Create the SSL server certificate by running the following script: 1 $./Tutorial_3_PKI_Create_SSL_ServerCert.sh 4.2 Setup a Secure Site on Apache Configure SSL Virtual Host. In this tutorial, an additional Virtual Host will be created that serves SSL Secured pages (Https). By default, during installation of Apache a default SSL Virtual Host is created (i.e., /etc/apache2/sites-available/default-ssl.conf) but not activated. The file defines access to the web server through Https at default Https port 443. It serves pages from the same DocumentRoot /var/www as the insecure site serves at port 80. Have a look at the configuration file /etc/apache2/sites-available/default-ssl.conf Notice that by default the configuration file already specifies a certificate and key file (ssl-cert-snakeoil.pem and ssl-cert-snakeoil.key) that can be generated automatically for demonstration purposes($ make-ssl-cert generate-default-snakeoil) to setup a simple SSL server using self-signed certificates. In order to configure the Secure site to use our custom PKI, the configuration file must point to the files, we created for our secure web server. We, therefore, need to replace the following files with our own: Page 26 of 41

27 1 SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem 2 SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key In addition, since the server certificate is issued by a root authority (not self-signed), we must point the configuration file to the correct server certificate chain. The following line is uncommented (i.e., remove #) and the server certificate chain is copied to the file specified: 1 #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt This certificate chain will be sent to the client while the connection is made. This allows the client to verify that the root of the chain is part of the trusted root authorities maintained by the client. Enable the new Virtual Host. Before we can activate a Virtual Host that uses SSL on the web server, the SSL module must be activated once: 1 a2enmod ssl // activate SSL Module Enabling the newly configured Virtual Host (defined by /etc/apache2/sites-available/default-ssl.conf) is simple and can be performed as follows: 1 sudo a2ensite default-ssl // activate SSL Site 2 sudo service apache2 restart First, the site is added to the configuration of Apache, followed by a restart of Apache s web server making the changes effective. Apache makes use of two folders to activate and deactivate websites: /etc/apache2/sites-available contains the configuration files of sites that can be set active. /etc/apache2/sites-enabled contains the configuration files of sites that are active. The a2ensite command makes a logical link from the former to the latter when enabling the site. To deactivate the site a2dissite removes this link and the site is no longer active. Configure the site, enable SSL and activate the secure site by executing the Tutorial 4 Apache Setup Server Authentication.sh script: 1 $./Tutorial_4_Apache_Setup_Server_Authentication.sh In addition, a number of files (certificates, chains, keystores,...) are copied to the website, that will be fetched by the mobile in later steps. Notice that the extension of the rootca.pem file is changed into.crt. This will allow the android built-in browser to import the certificate when downloading it through the browser. Page 27 of 41