Creating Your Own Self-Signed Certificate for Testing

Figure 7-5. Untrusted certificate warning

Now that you have been thoroughly warned about using the following section for testing only, let’s proceed to create and sign our own certificates for testing purposes. This will allow us to build our infrastructure in a separate environment before moving to a proper production environment with a trusted certificate authority.

In the previous sections, you learned about the fundamentals of setting up a production-level certificate. Now let’s go through the steps needed for setting up our own certificate.

Certificate setup

The first step is to create our private key and the self-signed certificate that we will be using when we spin up a Node server instance.

For the sake of the example, we’re going to store our keys in the same folder as the program that we will be running. With that said, load up a terminal window and go to the folder you are using for this program.

Let’s start with the private key setup. Type in the following command:

openssl genrsa -des3 -out server.key 2048

You will be asked to enter and verify a password for the file. What you are essentially doing is creating a new 2048-bit, triple-DES-encrypted RSA key; encrypting it with a password; and then storing it to a file, server.enc.key.

The process looks like Figure 7-6.

Figure 7-6. Generating a 2048-bit RSA key

Next up, we need to create a certificate signing request (CSR). Using our previously generated key, we issue the following command:

openssl req -new -key server.key -out server.csr

This will create our certificate signing request, with the intent of outputting the CSR to server.csr. After issuing the command, you will be required to input more detailed information about yourself and your company.

• The passphrase used for the private key (the same one used for the last command)

• Your two digit country code

• Your state or province

• Your city or locality name

• Your company or organization name

• The group or unit that this belongs to in the company

• Any common name to be used for the certificate request, or your name

• An appropriate email address to contact

You will also be asked to add a few extra attributes, including these:

• A challenge password

• A company name (optional)

The entire process, end-to-end, looks like Figure 7-7.

Figure 7-7. Creating a certificate signing request

Removing Key Encryption

If you are using the self-signed certificate for testing and wish to remove the password and encryption from your private key (not recommended for anything but single-user, local testing), then at this point you could use your previously generated encrypted private key (say that’s server.enc.key), and generate the new unencrypted private key (server.key) with the following command:

openssl rsa -in server.enc.key -out server.key

The list of commands to issue to get to the same point as we were in this section, using this method, are shown here:

openssl genrsa -des3 -out server.enc.key 2048
openssl req -new -key server.enc.key -out server.csr
openssl rsa -in server.enc.key -out server.key

Now that we have our CSR in place, we can self-sign the certificate to create our needed certificate file (CRT), using the following command:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

This command creates a temporary certificate for one year (specified by the -days option). If you did not remove the encryption from the original key file, then you will be required to enter the key passphrase for this step, as shown in Figure 7-8.

Figure 7-8. Creating the self-signed certificate

Our self-signed certificate is now ready for us to use in our server setup, to start creating secure HTTPS connections between the server and browser.

npm install body-parser --save

var fs = require('fs'),
    https = require('https'),
    querystring = require('querystring'),
    bodyParser = require('body-parser')
    app = require('express')();

//support JSON & URL encoded bodies
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({
    extended: true
}));

//handle all POST requests
app.post('/', function (req, res){
    var message = req.body;
    res.send('Message received:' + querystring.stringify(message));
});

//set certificate options
var options = {
   key: fs.readFileSync('server.key'),
   cert: fs.readFileSync('server.crt'),
   passphrase: 'YOUR KEY PASSWORD'
};

//create server with certificate options
https.createServer(options, app).listen(3000, function () {
   console.log('Server started: Listening on port 3000');
});

node server.js

Making secure requests to the server

Note

The client code for the following example is available in its entirety at https://github.com/iddatasecuritybook/chapter7/blob/master/self-signed-cert/client.js.

Our client script, client.js, is a fairly standard POST request, with a few differences. We’ll look at the full code next, then describe each of the sections (and any caveats):

var querystring = require('querystring'),
    https = require('https');

//POST data to be sent to server
var postData = querystring.stringify({
    'message' : 'My secure JSON string'
});

//POST options
var postOptions = {
    hostname: 'localhost',
    port: 3000,
    path: '/',
    rejectUnauthorized: false,
    method: 'POST',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
        'Content-Length': postData.length
    }
};

//set up HTTPS POST request to server
var postReq = https.request(postOptions, function(res){
    res.setEncoding('utf8');
    res.on('data', function (data){
        console.log(data);
    });
});

//POST data to server
postReq.write(postData);
postReq.end();

We start things off by including the querystring and https standard Node modules.

We then create the JSON object that we will be sending through the HTTPS POST request, post_data. We add just a simple string for our needs, then stringify the entire object for POSTing.

Under the POST options, this is where we need to pay attention to slight differences from a standard POST request with a non-self-signed certificate. Within the POST options, we specify a few options:

hostname

The host to send the request to. Because we’re running the server locally, this is localhost.

port

The port to make the request to. The server is on port 3000, so that’s what we specify here.

path

The path to make the request to. The server is accepting all POST traffic to the same handle, so this can be anything.

rejectUnauthorized

This is the one to take note of. Specifying this as false will allow you to make POST requests with a self-signed certificate without being blocked by a certificate error.

method

The HTTPS request method, in this case POST.

headers

Our content headers, specifying content type and length.

Tip

Adding rejectUnauthorized: false to your POST options will allow you to work with a self-signed certificate without receiving error messages about the certificate not being trusted. The error produced, when not properly handled, will throw an error much like Figure 7-9.

Figure 7-9. Error thrown when making POST requests with a self-signed certificate

Next we set up the HTTPS POST request object. We do this by using https.request(…), passing in the post_options variable. In the response, we set the encoding of the response, then handle the case where data is sent back from the server with res.on(…). In the case of our client, we are simply logging out the response.

Lastly, we send off the POST request to the server. If all went well, we should see the response shown in Figure 7-10 when using our client.

Figure 7-10. Response from HTTPS POST request

Use Case

Let’s look at a practical scenario of when this will be valuable. Suppose you’re walking around a store with your mobile phone, and the store uses a series of BLE (Bluetooth low energy) devices, also known as beacons, for in-aisle purchasing. The device allows a phone to connect to it, and then it connects to a web endpoint to process the message. In this case, the messages may be to check the users in with their account, or to pay for their goods through a store credit card or PayPal account. These BLE beacons themselves are not secure devices and can be modified by a malicious party. We want to ensure that when users are sending their login information, the beacon hasn’t been modified to transmit that clear-text data to a malicious endpoint instead of the store endpoint.

This is where public/private keys come in. The person sending the message encrypts the message with the public key of the recipient (perhaps through a public keystore that verifies requests from the application asking for the public key), and then signs the message with his private key (in the case of the person walking around the store, this might be embedded within their store application). The encrypted and signed versions of the message are transmitted through the beacon, and on to the store API endpoint. That store API endpoint then decrypts the encrypted message with its private key (perhaps stored securely on its servers), and the signed version is verified using the public key of the sender (the person walking around the store).

We have now decrypted the message and verified its origins. In doing so, we’ve mitigated a number of potential attack vectors:

• A malicious party cannot simply watch cleartext traffic through the beacon and store any sensitive information going back and forth, because we encrypt the data end-to-end.

• A malicious party cannot send fake data through to the endpoint with hopes of gaining user account access, as the private key is known only to the user, and the message verification would fail without the public-key signing.

• A malicious party cannot force the beacon to push data to its own endpoints and expect any valid results. The data might arrive, but without a method of decrypting the data or checking its validity, the information would not be beneficial.

Let’s break this down into a simple process, shown in Figure 7-11.

Figure 7-11. Asymmetric cryptography process

These are the steps that you follow as you transmit data:

1. You generate two sets of keys, public/private keys for the person sending the data (sender), and another public/private key set for the person receiving the data (receiver).

2. You create a small message (typically a string/JSON object or the like) that you would like to transmit.

3. From the sender side, you take that message and encrypt it with the receiver’s public key, then take the encrypted message and sign it with your private key.

4. You transmit the encrypted and signed data to the recipient, sometimes through an intermediate device or service.

5. The recipient verifies the signed payload with the public key of the sender, then (if valid) decrypts the encrypted message with their private key.

You now have a verified and decoded message that can be processed as needed.

Advantages, Disadvantages, and Uses of Aynchronous Cryptography

Aynchronous, or public key, cryptography has advantages when compared against synchronous cryptography methods. In the same light, we also have to deal with a few drawbacks with this method.

Let’s look at a few of the benefits here:

Key convenience

Because each party (sender and receiver) has their own private key, and that key doesn’t need to be transmitted, we don’t have to deal with trying to find a secure method for transmitting that data as we do in a synchronous environment.

Key nonrepudiation

Because each party owns their own private key, and that value is never shared, an attack case involving a piece of data with an authenticated server but a potentially compromised key is a nonissue. Each party is responsible for the secure storage of their private keys, meaning that this issue doesn’t come up.

Now, we are dealing with one pretty big negative when working with this method:

Speed

Because a lot of processing needs to happen during encryption and decryption when using this method, it is quite slow when compared to a synchronous model.

With all of this said, asynchronous cryptography is not overly well suited for a single-user environment, where you might be encrypting data to be sent between two parties that you own. This is where synchronous cryptography shines. This method works well in a multiuser environment, where the channels between a sender and receiver might not be secure.

Initialization Vector

Many of the cryptographic algorithms that we are likely to use are what we call iterative algorithms. When a piece of data that is to be encrypted is split into blocks for encryption, those iterative algorithms depend on the data from previously encrypted blocks in order to process the next subsequent block. In these cases, the first block of data that will be encrypted has no previous block to build, so it needs a piece of data to begin running the algorithm. This is the initialization vector.

An initialization vector is a fixed-sized piece of data that is typically required to be random, or at the least, pseudorandom. Typically, each time you are encrypting a new piece of data, you would supply a new, random, fixed-length piece of data.

Let’s look at a practical example. In the CBC encryption mode of operation (we will explore that in the next section), the way it works is by breaking the data to be encrypted into blocks. As the algorithm goes through each block, the plain-text block is XORed (exclusive or—A or B, but not A and B) against the previous encrypted block, before finally being encrypted together. Because the first block in the chain needs to have a previous block to XOR against, we need to supply that data. That data is the initialization vector.

Padding

In the case of certain block cipher algorithm modes, such as Cipher Block Chaining (CBC) described in the next section, when the data to be encrypted is split into blocks of data to be processed, the plain-text data that is to be encrypted needs to be an exact multiple of the blocks produced. This means that each block needs to be an equal size. In these cases, if we come across data that cannot be chunked up into equal blocks, we need to add some padding data to the blocks.

Several standard conventions are employed that set standards on what this dummy data should be. Let’s look at these visually. Let’s say that we want to encode the string “This is my block data.” If the cipher mode we are employing requires equal block sizes, it would split the data into three blocks of 8 bytes, represented with the hex values of each character:

+-----------------------+-----------------------+-----------------------+
|T  h  i  s  _  i  s  _ |m  y  _  b  l  o  c  k |_  d  a  t  a  ?  ?  ? |
+-----------------------+-----------------------+-----------------------+
|54 68 69 73 20 69 73 20|6d 79 20 62 6c 6f 63 6b|20 64 61 74 61 ?? ?? ??|
+-----------------------+-----------------------+-----------------------+

Those three characters at the end will be the padding that we need to add to the string. Let’s see how this looks with each convention:

Each padded byte is the value of the total number of bytes needing to be added

Each byte of padding is set to the value of the total number of bytes of padding. In this case, we have 3 bytes of padding, so we set the value to 03:

+-----------------------+-----------------------+-----------------------+
|T  h  i  s  _  i  s  _ |m  y  _  b  l  o  c  k |_  d  a  t  a  _  _  _ |
+-----------------------+-----------------------+-----------------------+
|54 68 69 73 20 69 73 20|6d 79 20 62 6c 6f 63 6b|20 64 61 74 61 03 03 03|
+-----------------------+-----------------------+-----------------------+

The first padded byte is 0x80, followed by 0 bytes for the rest

For this one, we set the first byte of padding to 0x80 and all subsequent padding bytes to 0:

+-----------------------+-----------------------+-----------------------+
|T  h  i  s  _  i  s  _ |m  y  _  b  l  o  c  k |_  d  a  t  a  _  _  _ |
+-----------------------+-----------------------+-----------------------+
|54 68 69 73 20 69 73 20|6d 79 20 62 6c 6f 63 6b|20 64 61 74 61 80 00 00|
+-----------------------+-----------------------+-----------------------+

Each byte is set to 0 except the last byte, which is the number of the total bytes of padding

This is a take on the first method, but we set all bytes of padding to 0, with the exception of the last byte, which should be equal to the total number of bytes of padding. In the case of our example, that will be 03:

+-----------------------+-----------------------+-----------------------+
|T  h  i  s  _  i  s  _ |m  y  _  b  l  o  c  k |_  d  a  t  a  _  _  _ |
+-----------------------+-----------------------+-----------------------+
|54 68 69 73 20 69 73 20|6d 79 20 62 6c 6f 63 6b|20 64 61 74 61 00 00 03|
+-----------------------+-----------------------+-----------------------+

All bytes are set to 0

All bytes of padding should be set to 0:

+-----------------------+-----------------------+-----------------------+
|T  h  i  s  _  i  s  _ |m  y  _  b  l  o  c  k |_  d  a  t  a  _  _  _ |
+-----------------------+-----------------------+-----------------------+
|54 68 69 73 20 69 73 20|6d 79 20 62 6c 6f 63 6b|20 64 61 74 61 00 00 00|
+-----------------------+-----------------------+-----------------------+

All bytes are set to spaces (0x20)

All bytes of padding should be set to spaces:

+-----------------------+-----------------------+-----------------------+
|T  h  i  s  _  i  s  _ |m  y  _  b  l  o  c  k |_  d  a  t  a  _  _  _ |
+-----------------------+-----------------------+-----------------------+
|54 68 69 73 20 69 73 20|6d 79 20 62 6c 6f 63 6b|20 64 61 74 61 20 20 20|
+-----------------------+-----------------------+-----------------------+

How padding works is something that we should understand when choosing a proper mode of operation, because it can be costly depending on the data that is to be encrypted. In each case of the padding, the decryption process needs to know how to properly determine which method was used, and how to properly disregard padding values.

In the case of the algorithms that we are going to use in the practical examples that follow, padding will be taken care of for us, so it’s not something that we need to be concerned with in our implementations.

Block Cipher Modes of Operation

Understanding the potential modes of operation is important when working with data encryption. A mode of operation is an algorithm that uses a block cipher (such as AES) to provide functionality such as confidentiality or data authentication for the block of information to be encrypted.

Within the case of our web operations, we will be working with three main categories of modes:

Encryption

This means, in general terms, data privacy/confidentiality. A potential attacker who has the generated ciphertext (the encrypted data) will not be able to get any information about the plain-text data, except for the length perhaps.

Authentication

Authentication mode provides a mechanism for determining data authenticity. If a receiver obtains ciphertext or cleartext from a sender, they can determine whether the data is genuine and was constructed by the sender.

Authenticated Encryption

This includes both previous categories.

Now that we have an understanding of the categories, let’s look at some of the NIST-approved block cipher modes of operation¹ (Table 7-1). Many of these modes range heavily in how they function, but at the end of this section we list the most popular industry-standard modes.

If you want to protect the privacy of the data that you are sending, but don’t necessarily need to authenticate the sending source of the data, then the mode under the encryption category will fill that need.

If confidentiality is not required for the message being sent, that’s where the authentication mode will come into play. For instance, if you just need to know that the message came from an approved sender, but the message itself is not sensitive in terms of data privacy, then the mode of operation in Table 7-2 is probably best.

In many cases you probably want to not only maintain the privacy of the data being transmitted, but also verify the source of the data for additional security. In this case, the combined authenticated encryption modes listed in Table 7-3 are an excellent option.

Even with a basic understanding of the preceding tables, it can be difficult to choose the best modes of operations in each category. If we break them into current industry-standard use, these are the most popular modes of operation in each category:

• Encryption: CTR (for good parallelization/speed)

• Authentication: CMAC (because it’s the only approved one, although it’s not widely used in the industry)

• Authenticated Encryption: GCM (industry-accepted standard)

Now that you have an understanding of modes of operation, let’s apply these to a few examples, starting with AES using the CTR encryption mode.

Using AES with CTR Encryption Mode

We have all the our core basics to start looking at using a cipher algorithm (AES) with a particular mode of operation (CTR encryption in this case).

We’re going to be using the standard Node crypto package for this example, so there is nothing to pull down from npm. At the top of your Node script, add the following initialization variable:

var crypto = require('crypto');

Now we need to set the variables that we are going to be working with in the example:

var text = "Encryption Testing AES";
var key = crypto.randomBytes(32);       //256 bit shared key
var iv = crypto.randomBytes(16);        //initialization vector - 16 bytes
var algorithm = 'aes-256-ctr';          //cipher and mode of operation

Going from top to bottom, these are as follows:

text

The data to be encrypted/decrypted.

key

A 32-byte shared key to be used by the crypto library for encryption/decryption. We use the crypto.randomBytes(…) method to generate that string.

iv

The initialization vector, which should be a random 16-byte string. We use the crypto.randomBytes(…) method to generate that string.

algorithm

The cipher algorithm and mode of operation to use. In this case, we’re using the AES cipher algorithm with the CTR mode of operation.

Next, we create the ciphertext by encrypting the data:

var cipher = crypto.createCipher(algorithm, key, iv);
var encrypted = cipher.update(text, 'utf8', 'hex');
encrypted += cipher.final('hex');

We first make a call to crypto.createCipher(…) to initialize the cipher that we want to use, passing in the algorithm/mode, the shared key, and the initialization vector.

Next, we use cipher.update(…) to update the cipher with data. We supply the data to be encoded, the input encoding utf8, and the output encoding hex.

Lastly, we make the request to cipher.final(…), passing in the output encoding type, to return the ciphertext.

Our plain-text input is now encoded. At this point, there should be a few things known about the ciphertext and decryption:

• The ciphertext can now be transmitted to its end source (the receiver).

• The shared key and initialization vector must be known to the receiver to decrypt. The key should be a shared secret between the app and the host (sender and receiver), and the IV can be considered as a one-time-use nonce, shared between both parties.

Now, let’s say the cipher has been transmitted to the receiver, and they also have the key and initialization vector. We can now begin deciphering the ciphertext to extract our plain-text message:

var decipher = crypto.createDecipher(algorithm, key, iv);
var decrypted = decipher.update(encrypted, 'hex', 'utf8');
decrypted += decipher.final('utf8');

We start by making a call to crypto.createDecipher(…), passing along the same values that we did for creating the cipher during encryption.

We then call decipher.update(…), passing in the ciphertext, the ciphertext encoding (in this case, hex), and the intended output encoding (in this case, utf8).

Lastly, we call decipher.final(…) with the output encoding type to retrieve our final decoded message.

Using AES with with GCM Authenticated Encryption Mode

Now let’s look at an example that uses the GCM joint authenticated encryption mode of operation. This one is fairly similar to the previous CTR mode example, but with an additional encryption/decryption step to handle the authentication piece that we didn’t have in the CTR mode example.

We’re again going to use the standard Node crypto package, so require that at the top of your Node script:

var crypto = require('crypto');

Next, we initialize the variables that we are going to be using:

var text = "Encryption Testing AES GCM mode";
var key = crypto.randomBytes(32);       //256 bit shared key
var iv = crypto.randomBytes(16);        //initialization vector - 16 bytes
var algorithm = 'aes-256-gcm';          //cipher and mode of operation

As before, these variables are as follows:

text

The data to be encrypted/decrypted.

key

A 32-byte shared key to be used by the crypto library for encryption/decryption. We use the crypto.randomBytes(…) method to generate that string.

iv

The initialization vector, which should be a random 16-byte string. We use the crypto.randomBytes(…) method to generate that string.

algorithm

The cipher algorithm and mode of operation to use. In this case, we’re using the AES cipher algorithm with the GCM authenticated encryption mode of operation.

Now, let’s encode the data to get our ciphertext, and see the differences when we add the authentication piece:

var cipher = crypto.createCipher(algorithm, key, iv);
var encrypted = cipher.update(text, 'utf8', 'hex');
encrypted += cipher.final('hex');
var tag = cipher.getAuthTag();

We first make a call to crypto.createCipher(…) to initialize the cipher, passing in the algorithm/mode, the shared key, and the initialization vector.

Next, we use cipher.update(…) to update the cipher with data. We supply the data to be encoded, the input encoding utf8, and the output encoding hex.

We then create the ciphertext by calling cipher.final(…) with the output formatting.

This is where the authentication piece comes in; after we have the ciphertext, we have to generate a tag by calling cipher.getAuthTag(…). This will be a Buffer containing an authentication tag that has been computed from the cipher data. This will be used to authenticate the source of the ciphertext.

As in the previous example, the ciphertext should be transmitted to the receiver. The receiver should also have knowledge of the shared key, the initialization vector, and the authentication tag:

var decipher = crypto.createDecipher(algorithm, key, iv);
decipher.setAuthTag(tag);
var decrypted = decipher.update(encrypted, 'hex', 'utf8');
decrypted += decipher.final('utf8');

We make our call to crypto.createDecipher(…), passing along the same values that we did for creating the cipher during encryption.

Following that, we need to pass in the authentication tag to validate the source of the ciphertext. We do so by calling decipher.setAuthTag(…), passing in the tag that was generated from the encryption step.

Next, we go back to the standard decipher techniques by calling decipher.update(…) to pass in the data, providing the ciphertext, ciphertext encoding (in this case, hex), and the intended output encoding (in this case, utf8).

Lastly, we call decipher.final(…) with the output encoding type to retrieve our final decoded message. The ciphertext will now be decoded and the source authenticated, allowing us to use the data at will.

Advantages, Disadvantages, and Uses of Synchronous Cryptography

As we close out our exploration of synchronous cryptography, it’s a good idea to understand what it does well, and what it doesn’t do well.

Using this method over its asymmetric counterpart has some advantages:

Security

When we are using a secure algorithm, such as the US government–designated Advanced Encryption Standard (AES) that we looked at previously, the ciphertext that is produced is incredibly secure, and is considered essentially unbreakable with current computing standards.

Speed

One of the main issues with asymmetric key cryptography is the complexity of the process that it needs for encryption and decryption. With symmetric cryptography, using modes of operation that allow for parallel block processing for encryption and decryption, we have a fast processing mechanism.

If we flip the coin, though, this methodology has one major drawback:

Shared key

As you saw in the practical examples, we generate a single shared key that is used by the sender for encryption, as well as the receiver for decryption. You need to take great care in ensuring that this key can be shared between both parties, without being retrieved by an attacker. Should this key be obtained by an illicit third party, they now have access to all encrypted data that is using that shared key. This means that the amount of damage that may be caused by using this method is typically quite high.

With all said and done, one of the best methods for using this type of cryptography is when you’re encrypting and decrypting your own data, when you have safe, secure access to shared keys between endpoints. All in all, if you have a safe way to share the key between yourself and an unknown party, you probably don’t need to be using your own encryption in the first place.