A Proposal to Use X.

509 Mutual Authentication for

CCHS Connected Home Cloud Based Services
Stephen Mansfield, CCHS Senior Software Architect
August 2015

Abstract -- Cloud based services are becoming an

important business tool in the growth of enterprise
computing applications. The ability to build, deploy,
and scale large enterprise applications in a matter of
seconds is greatly appealing to today’s fast responding
internet based companies. Although cloud bases
computing services have inherent strong security and
support all of the industry security standards, special
considerations must be made before integration into
existing non-homogeneous enterprise server/networks
security architectures. This paper presents an Amazon
AWS cloud based computing services security
integration strategy into a CCHS enterprise
computing/network topology utilizing X.509 mutual
authentication. The motivation is to improve the service for the appliance at the customer’s convenience.
company’s 2 factor computer network authentication The central component to this new service is a newly
policy and make integration of cloud based services developed CCHS cloud based service management
easier by eliminating the need for white listed IP platform or SMP. The connection architecture is
security. highlighted in figure 1. Technically, the Connected
Home SMP is a cloud based Platform as a Service (PaaS).
Keywords -- Internet of Things (IoT), X.509, PKI, SSL, It orchestrates and manages the flow of diagnostic and
TLS, IPv4, IPv6, AWS, Elastic IP, Load Balancer, WiFi, service information across several platforms. Other
Zigbee, Zwave, Bluetooth, Symmetric Encryption, value add services can also be integrated onto this
Asymmetric Encryptions, Secure Hashing Encryption, platform such as home energy management, intelligent
comfort and lighting, as well as home security.

Introduction
CCHS Connected Home is a new business venture that is
focused on developing an end to end digital appliance
warranty service. The service, utilizing Internet of
Things (IoT) technology, enables a customer to monitor
and control the operation and status of appliances in
the home with a smartphone. If an appliance fails, the
customer is notified of the failure, taken through a
service triage process, and automatically schedules
The service flow for this architecture starts with IoT
enabled appliances. IoT appliances connects to the
internet either through WiFi or an internet connected
hub. These devices connect to a 3rd party IoT Device
Service Platform (IoT DSP) that manage device
connectivity. The Service Management Platform
receives alerts from the IoT Device Service Platforms
and determines the appropriate actions. It can alert
customers using there smart phone or create service

June 2015 CCHS Connected Home 1

action through CCHS Timex ERP. Timx is an ERP
platform and manages virtually all service warranty
actions. It is used exclusively by CCHS service
representatives to manage and support all warranty
service claims. Once it has been determined that a
service call is required the SMP signals a 3rd party
Service Support Platform (SSP). This platform forwards
service requests to the correct service trade, schedules
appointments, and reports on status of the repair.
Status of the service call is sent back to the Service
Management Platform and made available to the
customer. The customer can view scheduled service,
re-schedule, cancel, and determine if the service
tradesman has been dispatched.
CCHS Two Factor Authentication
The Service Management Platform interfaces to a
multitude of both internal and external platforms. A
later paper to this one will focus on the overall
Connected Home Service Management Platform
security architecture. This paper focuses on the
security surface between the CCHS Timx ERP and the
Service Management Platform API.
Today the primary interface for consuming external
services is through the Timx API. This API uses two
factor authentication --white listing of IP addresses, and
a static bearer token. White listing of IP address uses an
internet facing router or firewall to block any access
that don’t match an approved IP list. If an external
client or server with an IP address that is not on the
approved list tries to access the API endpoint the
request is blocked.
A static bearer token is a secret token that is sent along
with each TCP header. The API software verifies the
authenticity of the token by matching. If the token does
not match the API command is rejected.
The API also used TLS encryption to protect the content
of the data. A signed digital certificate is used to
exchange encryption keys but only the server is
required to have a valid certificate signed by a trusted
Certificate Authority (CA) like Symantec or Comodo.
We will talk more about certificates and key exchange
later.
June 2015 CCHS Connected Home
Although white listing and static bearer token is
considered good security technology there are a
number of issues when used with dynamic cloud based
systems. White listing is very difficult to manage with
dynamic cloud instances. One of the great benefits of
cloud computing is the ability to dynamically scale
processor instances. For web based instances these are
most usually internet facing and thus must have a
unique IP address. When an instance is created it is
given a dynamic IP address from a pool of IP addresses
provided by the cloud service provider. When an
instance is created it is given the next available IP
address in the pool. When the instance is terminated it
returns the IP address back to the pool. Dynamic
instance IP allocation is the most efficient internet
connection point for dynamic cloud services. Some
cloud service providers offer single point IP services, like
Amazon’s Web Services (AWS) elastic IP’s. Elastic IP are
used in conjunction with Elastic Load Balancers (ELB)
and provide a single IP address externally with multiple
private IP connections for internal processor instances.
Amazon on provide 5 EIP’s. More can be obtained but
permission from Amazon is required. ELB work well
with applications that have only a few public IP
addresses and the architecture is fairly stable. ELB’s do
not work well in multi-geography highly scalable
platforms. White listing of IP with dynamic cloud
instances are clearly problematic. They are also difficult
to manage and require periodic auditing client platform
security.
There are also issues with static bearer tokens. There is
only one token for all clients and the token never
changes. This makes token revocation management
difficult. The token is basically a single secret that is
shared among all internal and external users.
Whenever you wish to revoke token credentials from a
single user, the single token must be revoked and a new
one re-distributed to all other clients. Static bearer
tokens also misses the opportunity to utilize dynamic
bearer tokens for authorization. Since each token is
unique to a user, you can use dynamic bearer tokens to
allow certain user privileges depending on the role of
the client. It is recommend that future releases of the
API include Oauth2 authentication tokens.
2
Authentication tokens are not only user unique they are
also time persistent – typically 1 to 3 hours.
As an alternative to white listed IP’s, a new network
security technology called mutual authentication is
proposed. Mutual authentication allows authentication
of clients and servers with any IP address. They use
public certificate exchange to verify trust between both
the server and client. They are also easy to implement
and provide a number of security management
efficiencies that white listed IP do not. It also works out
in the present CCHS Timx API that this service can be
implemented with no server side code changes. Some
minor code changes are required on the client side.
Overview of Digital Certificate Security
Mutual client/server authentication utilizes several
encryption technology standards. The most important
is X.509, PKI, and TLS. X.509 basically describes digital
certificates, the certificate content, creation, and the
concept of trust and a Certificate Authority. PKI stands
or public key infrastructure and describes several
algorithms that allow for public/private asymmetric
keys. The public/private key allows easy digital signing
of electronic documents or certificates and data
encryption. TLS stands for Transport Layer Security and
is an encryption standard that defines what encryption
algorithms and how data packets in the IP frame are
encrypted. TLS generally uses a single symmetric key
for encryption. Triple DES, AES, and AES256 are
common encryption algorithms for TLS. However, AES
or AES256 are recommend. An older version of IP
encryption is called SSL (Secure Socket Layer) security
and is considered obsolete. SSL and TLS are often used
interchangeably but almost all IP security is TLS driven.
Public Certificates
Central to all modern encryption is the concept of
digital certificates. In common literature I find he
definition of a digital certificate are often maligned.
The certificate is a document with administrative
information in English describing the owner, address,
contact information, and additional information about
who generated the certificate. It also contains a secure
and encrypted hash of the certificate along with a valid
public key. The certificates only duty is to provide a
June 2015 CCHS Connected Home
valid public key and create a chain of trust between the
certificate itself and the certificate authority that issued
the certificate. The certificate authority is often called
the CA. The process goes something like this. The CA
first creates a certificate with information about the
individual or company that has requested a certificate.
The CA also creates a public/private key pair and inserts
the pair into the certificate. A hash is also created to
validate the integrity of the certificate. At this point the
certificate is called a Certificate Signing Request or CSR.
The CA then creates a public certificate called a CRT.
The CRT contains the owner’s information like before
but also includes the information about the CA. The CA
hashes the certificate and encrypts the hash with its
private key. This private key comes from the CA’s Root
certificate. Whenever anyone wants to validate the
certificate they simply create a hash of the certificate
and decrypt the encrypted hash with the CA’s public
root key. The user then compares the two hashes and if
they are both the same the certificate can be trusted.
This is the key point. A root of trust has been created
between the certificate and the CA. When the hashes
match the user is assured that the certificate has not
been tampered with. The certificate does not
specifically validate its owner, company, address, or
other information. It simply verifies that the certificate
is authentic, has not been tampered with, and the
public key is a valid public/private key pair. One
exception is the website listed on the certificate. If a
browser is viewing an HTTPS site and using TLS, it does
verify the website URL in the server certificate against
the actual browser URL. There is also information in the
certificate that provides expiration dates and a location
where the certificate can be checked for revocation.
This certificate is also called a public certificate.
Self-Signed Certificates
Public certificates are sometimes expensive to
purchase. The cost of the certificate is driven by the
length of time the certificate is valid. There is also
administrative effort needed to go to a CA to get a
private CSR and public CRT and distribute between
servers and clients. An alternative to public certificates
is self-signed certificates. Widely available open
software tools like Keytool or OpenSSL easily allow
server administrators to create their own CSA and
3
CRT’s. A self-signed certificate has both the owner and
the CA as the same. In other words the public key in the
public certificate can decrypt the self-signed certificate
hash – it verifies itself. The CA asserts that the
certificate is a public certificate relies on the integrity of
the CA manage the secrecy of its private key and the
chain of trust between the CA and the certificate. A
self-signed certificate relies on the trust of the server
administrator to manage the secrecy of the private key
and the chain of trust is between the server
administrator and the certificate.

Many people believe a self-signed certificate is not as

trustworthy as a public certificate. Technically this is
not true. A self-signed certificate is created using the
same algorithms and tools as a public certificate. The
only difference is that the root of trust belongs to the
server administrator. Matter of fact, almost all public
CA root certificates are self-signed. The root of trust
certificates that your browser uses to verify the
authenticity of a server public certificate are all self-
signed. The only risk you have with self-signed
certificates is that someone has tampered with your SSL
tools in your server or your server private key gets
exposed. Common server security measure can
significantly mitigate these issues.
TLS Client/Server Authentication
Let’s go into detail how a server and client mange key
exchange and authentication in a TLS Server
Authentication sequence. TLS security is the most
common form of internet security. It sometimes goes
by SSL or HTTPS security however the actual security
protocol almost always used is TLS. This discussion will
be from the perspective between a server acting as an
endpoint and a client requesting API service.
TLS security utilizes a server certificate to principally
manage key secure exchange. It is possible for the
client to authenticate the server but it is rarely done.
Code could be written for the client to verify the
server’s certificate. A TLS sequence diagram is shown in
figure 2. When an HTTPS sequence starts the client
sends in the clear a client hello message along with
proposed client crypto information and a client random
number that will be later used for secure key exchange.
June 2015 CCHS Connected Home
The server then generates its own random number and
then also responds with a server hello, crypto
information, and the server random number. Next the
server send over its public certificate with its public key.
The client extracts the CA information from the
certificate and uses the CA public key to validate the
server certificate. The client then uses the server public
key to encrypt a hash of all of the messages sent back
and forth between the server and the client and send it
to the server. The server calculates its own hash and
verifies against the clients encrypted hash. This is make
sure all messages are accounted for and there was no
man in the middle attack. The client then generates
pre-master secret random number, encrypts it with the
server public key and sends it to the server. Both the
server and client multiply the client, server, and pre-
master secret to generate the AES256 symmetric key.
Both server and client have an identical AES symmetric
keys. Now the client signals the server to switch
encryption and use the AES key. It also ends the TLS
handshake. The server does the same with the client to
4
end the TLS handshake. Then at this point both the
client and server exchange data using AES encryption
until the HTTPS session is shut down. At this point the
AES keys are thrown away and not to be used again.

Mutual Authentication
Mutual authentication between a server and client are
very similar except both the server and the client verify
each other’s certificates. Server client verification is
taken care of by the reverse proxy server. In the case of
the Timx API that would be a Tomcat server. Client
server authentication is done with specific code written
in the client application. Basically mutual
authentication works by both the client and the server
exchanging there public digital certificates before the
actual message exchange.

Although the process is a little more complex basically

both the server and the client pre-exchange public
certificates. The server add the client certificate to a
special list of allowed clients. Similarly the client stores
a copy of the server’s certificate to a special list of
allowed servers. The server administrator has given the
client the server’s public certificate manually by email
or by other electronic means. Similarly the client gives
the server administrator his public certificate. Both are
in the open. The client then uses the public key from
stored as a list of approved client/servers. There is trust
the CA that issued the server certificate to decrypt the
because server administrator can trust the client to give
server’s certificates hash value. The client then
him a valid and certificate. There is also trust of the
generates its own hash and compares it to the
client to receive a valid certificate from the server
decrypted one. If they are the same the certificate is
administrator. Also, there is trust that both certificates
considered trusted. It then compares the hash value to
are authentic because they both can be verified by a CA.
the one earlier saved by the client. If they compare
Both are stored as a list of approved client/servers.
then the client has authenticated the server. The client
also makes sure the certificate has not expired or it is
The exchange of certificates for Mutual Authentication
not on a Certificate Revoked List (CRL). If there is no
starts out the same as Client/Server Authentication.
comparison, the certificate is expired, or is on a CRL, the
The sequence diagram for the exchange is highlighted in
client closes the connection with no response. Next the
figure 3.
client then sends its public certificate and key to the
server in the clear. The serer then uses the public key
First the client creates a random number and bundles it
from the CA that issued the client certificate to decrypt
with a client hello message along with crypto
the client’s certificates hash value. The server then
information that it sends in the open to the server. The
generates its own hash of the certificate and compares
server then generates its own random number and
the two. If they are the same the certificate is
bundles it with a hello server message along with crypto
considered trusted. The server then compares he hash
information and sends it in the open to the client. The
value with the one saved previously. If they match then
server then send the client its public certificate and key
the server has successfully authenticated the client.
June 2015 CCHS Connected Home 5
The server also makes sure the certificate has not
expired or it is not on a Certificate Revoked List (CRL). If
there is no comparison, the certificate is expired, or is
on a CRL, the server closes the connection with no
response. This point both the client and server have
authenticated each other. The client then generates a
pre-master key and sends it encrypted using the
server’s public key. Both the server and the client then
multiply the SRN, CRN, and PMS to generate a master
key. This key is used for symmetric encryption –
Typically AES256. Both client and server switch to
symmetric encryption and end the TLS handshake. At
this point both client and server begin exchanging data.
What we have shown here is both the client and server
securely authenticate each other using secure digital
certificates. There are two levels of trust in this
exchange. First, digital certificates that are signed by a
trusted CA validates that the certificates have not been
tampered with by either party and that they can be
trusted. Second, the server administrator provides his
certificate to the client. The client trusts that that
server administrator has given him the correct
certificate. It is of course in the best interest of the
server administrator to provide the correct certificate.
Similarly, the client provides the server with its
certificate. It is in the best interest for the client to
make sure it provides the correct certificate to the
server administrator. The secure exchange of
certificates are then used to generate a symmetric key
so that both parties now have a way to securely
exchange data.
The certificates used can be either public CA certified
certificates or self-signed certificates. There are pro’s
and con’s for each method. CA generated and signed
certificates are considered slightly more secure. CA’s
expend lots of money and resources making sure that
there process for generating key-pairs, creating
certificates, and guarding the CA’s private key is
absolutely secure. Some CA’s even use only hardware
generated keys and certificates believing that they
much more difficult to hack. Generating your own key
pair and certificates does expose the server
administrator to tampering with the servers open key
and certificate tools. CA certificates can be expensive.
Most organizations only purchase certificates that are
June 2015 CCHS Connected Home
valid for a few years. Self-generated certificates are
free. Server administrators can also assign very long
expiration dates. The certificate administrator can
assign very long expiration dates to self-signed
certificates. The management of CA certificates is only
slightly more complex than self-signed.
At this point the next layer of authentication begins –
static bearer tokens. This is done at the API level by the
server API. If the client bearer token does not match
the server bearer token the API rejects clients request,
closes the session, and returns a 401.
Creating Certificates
The process of setting up the server to handle mutual
authentication begins with deciding what certificate
type you will use – CA publicly signed certificate or self-
signed certificates. In either case there are several
common steps before you receive your CRT. You must
first generate your own public/private key-pair using an
open software tool like keytool or OpenSSL. The key-
pair file is .key, .jks or .p12 type. The file type depends
on which toolset you are using and the server operating
system. Using the key-pair file, you then create a CSR
containing the public key. The file type varies but is
usually a .csr type. The CSR is what you send to the CA
to get digitally signed. The CA returns a CRT that is
digitally signed with the CA public key. The file-type
again varies but is usually a .cer, crt, or .p10. If you are
using self-signed certificates you can generate your CRT
from the key-pair file. It uses its own public key to sign
the CSR.
KeyStore and Certificates for Tomcat
Tomcat is java based platform and the preferred key
tool is keytool. First we will generate the client and
server key-pair,
Server Key Generation
Keytool –genkeypair –alias serverkey –keyalg RSA
–keypass password –keystore server.jks –storepass
password
Client Key Generation
Keytool –genkeypair –alias clientkey –keyalg RSA
6
–keypass password –keystore client.jks -storepass Also a Spring Boot example is also shown in Appendix A.
password
The server key-pair would be stored in a secure location
for use with the Tomcat Server. The client key-pair
would be stored in a secure location for use on the
client platform. Next we need to generate both the
client and server public certificates and CRT’s.

Server CRT Generation

keytool –exportcert –alias serverkey –file server-
public.cer –keystore server.jks –storepass passoword

Client CRT Generation

keytool –exportcert –alias clientkey –file client-
public.cer –keystore client.jks –storepass password
Once the CRT’s have been generated they need to be
inserted into the key-pairs – the server CRT is appended
to the client key-pair file and the client CRT is appended
to the server key-pair file. The CRT’s are saved in the
key-pair file so they can be used in the certificate
authentication process.
Client Setup
As highlighted earlier, the client must specifically
authenticate the server certificate. The client must
have access to the file where the client public certificate
is stored as well as the key-pair file that includes an
appended server public certificate. An example of client
code is highlighted in Appendix B.

Client CRT Insertion

keytool –importcert –keystore server.jks –alias clientcert
–file client-public.cer –storepass password
-nonpromt
Server CRT Insertion
Keytool –importcert –keystore client.jks –alias servercert
–file server-public.cer –storepass password
Tomcat Server Setup
Summary
A proposal has been shown that allows mutual
authentication to be used in place of white listed IP.
The proposal uses X.509 digital certificates and mutual
authentication between the server and the client. The
author asserts that digital certificates is a more
convenient means to implement client/server
authentication. This is true especially in a dynamic
instance cloud computing platforms.

You must now set up the Tomcat server so that it will

correctly implement mutual authentication between
both the server and the client. Figure 5 shows how to
set up a port connector in config.xml.

June 2015 CCHS Connected Home 7

June 2015 CCHS Connected Home 8
June 2015 CCHS Connected Home 9
 Client Mutual Authentication
package house.myconnected.sslclient;
Appendix B
import java.io.IOException;

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.HttpException;
import org.apache.commons.httpclient.URI;
import org.apache.commons.httpclient.methods.GetMethod;

public class SSLClient {

static
{
System.setProperty("javax.net.ssl.trustStore", "c:/apachekeys/client1.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "password");
System.setProperty("javax.net.ssl.keyStore", "c:/apachekeys/client1.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "password");
}

public static void main(String[] args) throws HttpException, IOException {

HttpClient client = new HttpClient();

GetMethod method = new GetMethod();
method.setURI(new URI("https://localhost:8443/restserver", false));
client.executeMethod(method);

System.out.println(method.getResponseBodyAsString());

June 2015 CCHS Connected Home 10

References

1. IEEE “A Systemic Approach for IoT Security”, 2013 IEEE International Conference on Distributed Computing in
Sensor Systems, A. Raiahi, Y. Challal, E. Natalizio, Z. Chtourou, & A. Bouabdallah.
2. Microsoft “Web Service Security”, November 2005, A. Stamos, & S. Stender.
3. Apache “Tomcast 6.0 SSL Configuration How-To”, v6.0.44 May 8th 2015, Apache
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html.
4. “Configuring Tomcat SSL Client/Server Authentication”, October 22nd 2012, Maxim Porges.
http://www.maximporges.com/2009/11/18/configuring-tomcat-ssl-clientserver-authentication/
5. “Construct Secure Networked Applications with Certificates, Certificates add value to Public-key cryptography --
Parts 1 through 4”, January 12th 2001. Todd Sundsted. http://www.javaworld.com/article/2074889/learn-
java/construct-secure-networked-applications-with-certificates--part-1.html
6. “SMTP and Transport Layer Security (TLS) Tutorial”, December 1st 2014, Dr. Erwin Hoffmann, FEHCom.
http://www.fehcom.de/qmail/smtptls.html
7. OpenSSL Wiki Page, May 16th 2015. https://wiki.openssl.org/index.php/Main_Page
8. “Code Examples – Verifying Digital Signatures”, June 26th 2012, Technische Universitat Darmstadt.
https://www.flexiprovider.de/examples/ExampleSMIMEverify.html
9. “X.509 and SSL – A look into the complex world of X.509 and SSL”, July 5th 2007, Phil Dibowitz.
http://www.phildev.net/ssl/ssl_talk_uuasc.pdf
10. “X.509/SSL Guide”, Phil Dibowitz. http://www.phildev.net/ssl/
11. “Iot Hubs Expose Connected Homes to Hackers”, April 7th 2015, Paul F. Roberts, The Security Ledger,
https://securityledger.com/2015/04/research-iot-hubs-expose-connected-homes-to-hackers/
12. Intel Press Release “Intel Unifies and Simplifies Connectivity, Security for IoT”, December 9th 2014.
http://newsroom.intel.com/community/intel_newsroom/blog/2014/12/09/intel-unifies-and-simplifies-
connectivity-security-for-iot
13. Samsung Press Release “The internet of Things Needs Openness and Industry Collaboration to Succeed”, January
5th 2015. http://www.samsung.com/us/news/24395
14. “The Design of Secure System”, January 2010, Pre-publication release, E. Fernandez, E. Gudes, & M. Olivier

June 2015 CCHS Connected Home 11