Trust & Encryption - Theory

Yes

Do you trust me?

if (true) { why }
else      { !why }

Communication between client and server can be encrypted or not.

Communication between client and server can be between trusted parties or not.

Both statements are independant of each other.

There's no need to trust a server - but still traffic can be encrypted.

There's no need to encrypt traffic - but still a server can be trusted.

For secure and safe communication in an IoT environment encryption as well as trust should be an integral part of exchanging data.

Trust

Certificates and Chains of Trust

Trust establishes the identity of the parties involved, e.g. is server I'm contacting really the server it pretends to be?

This can be ensured with server certificates. On the other hand, client certificates ensure that the client is actual the client it pretends to be.

This can be used as an authentication approach and if the identity of the server as well as the client is confirmed, this is also known as mutual authentication.

Trust is usually invoked through certificates.

Certificates have a subject, usually the servername that the certificate belongs to.

This can also be a wildcard subject like *.myserver.com which will be valid for all subdomains of myserver.com.

A certificate can be digitally signed to ensure its identity. Usually a Certificate Authority (CA) signs the certificate.

This CA can in turn be signed by another CA and so an, creating a whole chain of CAs. This chain is commonly known as the Chain of Trust or the certification path.

If a certificate is not signed by a CA it's called a "self-signed certificate". These are mostly used for test scenarios, but should never be used in real production environments.

Certificates can also expire by using dates like "Valid From" and "Valid To" to determine if a certificate is valid or not.

In case a certificate or CA is expired, all following certificates in the Chain of Trust will no longer be considered as valid.

For "commercial" certificates, certificates that are signed by an official CA like Google, Let's Encrypt or VeriSign, a Certificate Signing Request (CSR) is used.

For this a key-pair is generated and the CSR is signed with the private key. The CSR contains the public key and is sent to and finally signed by the CA itself, returning the public certificate e.g. signed by VeriSign. This mechanism allows to generate certificates by preparing the main information and just having the CA sign it as a trusted authority.

Key-pair

All certificates consist of a key-pair - a private key and a public key.

The private key is indeed very private to the server and MUST NOT be shared with anyone else.

The public key is indeed very public and can be shared with anyone.

The key-pair consists of mainly two very large prime numbers and some mathematical magic allows for a mathematical one-way function with a trap door.

This function allows to en-crypt any message with the public key and to de-crypt this message with the private key.

So by giving out the public key to anyone, anyone can en-crypt a message to the server but only the server alone can de-crypt it with its private key. Therefore it's important that the private key is not shared with anyone, otherwise messages can be de-crypted by anyone possessing the private key and secure communication can be compromised.

This method is called public-key encryption, or asymmetric encryption (as the key for en- and de-crypting are different).

For more information, check out https://en.wikipedia.org/wiki/Public-key_cryptography

This key-pair is not related to any encryption while sending data between client and server.

Encryption on a transport level is accomplished by using different, random keys.

It's just used to generate a unique certificate with a unique fingerprint as a public certificate.

The private key part is amongst other things used for signing other certificates in the Chain of Trust. Tomcat needs access to the private key of the server specific certificate, to actually verify that the certificate is authentic.

However, certificates can also be used for e.g. emails where the private key is in fact used to en- or decrypt the mail on a content level!

ThingWorx

ThingWorx is mainly configured for server side trust.

In this case all connecting clients can ensure that the identity of the ThingWorx server is a trusted one - and not a fake server or an untrusted source.

Certificates and trust are usually triggered when a secure connection is established, via TLS / SSL - e.g. by calling https://<myserver.com>:443/Thingworx

The default port for a HTTPS (HTTP Secure / over TLS) connection is 443.

For "normal" HTTP configuration, certificates are not required.

Keystore

To establish trust, any client needs to know the public certificate of the ThingWorx server. This is usually stored in a keystore.

In ThingWorx, Tomcat needs to be configured with the location and the password of the keystore containing the certificate.

For each web-request Tomcat will then present the server certificate to the client.

The client can then verify through its own keystore if the certificate is trusted or not.

When operating in browsers, this is done via e.g. the Windows-Keystore.

For devices a custom, e.g. a Java-Keystore is required.

The keystore must contain the whole Chain of Trust as well as the server specific certificate and its key.

If the Chain of Trust is not stored completely in the keystore, or the key is missing / not accessible, the certificate validation process will already fail on server side.

Certificates in Windows

The default Windows-Keystore is actually pre-filled with lots of Root-Certificates, which start the Chain of Trust - such as Google, VeriSign or Microsoft.

Trust needs to start somewhere…

If the browser can trace the CAs of certificate back to a trusted Root CA, it's indicated by a green lock and the server will be trusted.

If the Root CA cannot be found, it's indicated by a red lock (not a purse) - meaning that the server is not trusted.

The server can still be contacted anyway, by manually acknowleding the risks (like identity theft or credit card scams).

As an example, here's the certificate for Wikipedia and its Chain of Trust, starting with the GlobalSign Root CA:

Trustworthy?

In the end, certificates only clarify the identity of a server.

If it is trusted or not, is completely up to the user / device.

This trustful relationship all comes down to the client keystore / truststore.

While the presenting server holds its certificate in the keystore, the verifying client holds the trusted certificates in the truststore.

Any certificate in the truststore will ensure the correct server identity.

Any unknown certificate will trigger a "Are you sure?" question in the browser. And as devices usually cannot respond to such a question, communication with an untrusted server can be forbidden by default.

There are also products, like PTC Navigate which will require a client certificate to not only ensure server identity, but also ensure that also specific clients are able to connect to the server.

Encryption

No matter if a server is trusted or not, as soon as HTTPS is used as a protocol, communication will be encrypted.

The certificate plays a role, but no matter if it's in the client's truststore, TSL forces encryption.

Client Hello

Usually the client contacts the server and sends a Client Hello.

With this it also sends a list of available cipher suites, the intended receiver (server name) and a list of available Signature Hash Algorithms to be used.

Cipher suites are used to determine which algorithms are used to establish a connection. The Signature Hash Algorithms define the Hash function, like SHA256 and the key / signature, like RSA.

In my environment usually the Elliptic Curve Diffie-Hellman key exchange is used to transfer public keys between server and client.

During the Client Hello information about the elliptic curves are also transferred.

For more information on these topics, see

Server Hello

After receiving the Client Hello, the server sends back the Server Hello.

This consists of multiple handshakes. In this phase, the server sends the preferred cipher suite (intersection of client and server suites) including the Signature Hash Algorithm to be used.

In the same step the server is sending off the certificate to the client for identity validation.

For establishing trust and validating the certificate, the server needs to know the private key for the server specific certificate.

The server also announces in the server key exchange what public key it's using for encryption to the client.

This key is not related to the certificate, but a random number from a newly generated key-pair.

Keys are exchanged between server and client and vice versa via the Diffie-Hellman key exchange.

Client Response

The client now sends in the client key exchange what public key it's using for encryption to the server.

This is also a random key transmitted via the Diffie-Hellman key exchange.

Initiating Communication

After announcing the public keys, both server and client will now communicate encrypted by using their custom key-pairs for asymmetric encryption of the payloads.

This can also include an additional change of the cipher specification.

As the public keys have been exchanged via the Diffie-Hellman key exchange, server and client are now bi-directionally communicating using each other's public key to en-crypt a message and each's own private key to de-crypt the message again.

For more information, also see https://tools.ietf.org/html/rfc5246

Trust & Encryption - Hands On

Do you trust me now?

if (true) { why }
else      { !why }

To see how this all works in a ThingWorx enviroment, and how easy it actually set up what has been discussed above, see also Trust & Encryption - Hands On