Mutual Authentication

Introduction

When an HTTPS connection is established, usually only the server is authenticated by the client. This is known as one-way authentication. The server will send a certificate chain, and the client will authenticate the signatures starting from the root of the chain. Normally, the browser on the STB (the client) has several root certificates issued from several certificate authorities (CAs), and it searches for one that matches the CA used to sign the root of the server's certificate chain.

It is also possible to have a mutual, or two-way authentication where the server authenticates the client as well. Both types of authentication are handled automatically by the browser once configured.

To implement the most reliable authentication, the server should be using a certificate signed by a CA with limited exposure, e.g. ARRIS, while requiring the STB to use a device-specific certificate. This setup will almost guarantee that both sides are whom they claim to be.

The next best solution is to use a regular HTTPS connection using any certificate issued by a well-known CA. But since such a CA may have signed certificates they should not have, you may want to consider an extra level of authentication at the application level (see the section on signing and verifying).

As a lightweight type of authentication, it is also possible to just sign data and send it over HTTP. This is considered insecure because it is susceptible to reply attacks; servers do not have any mechanism to verify that the data is actually coming from your Set-Top Box.

Keys and Certificates

To perform mutual authentication, both the server and STB will need a certificate to show who they are. In addition, they will also need each others root certificates (a certificate signed by the others private key) in order to authenticate that certificate.

The following certificates and keys are used:

• Server root certificate: provided by the operator, and installed into the STB when building the boot image
• STB root certificate: provided by ARRIS, and needs to be copied to the server
• Server-side certificate: provided by the operator, signed by the server root certificate
• STB device-specific certificate built into the STB in the factory
• Server private key: located on the server, used to sign data
• STB private key: built into the STB in the factory, used to sign data

Authentication Process

The authentication process begins with the client contacting the server with a clientHello message (see the TLS protocol for exact protocol details). The server sends its server-side certificate to the client. The client uses its copy of the server root certificate to authenticate this. Once done, the STB knows that the server is the one it claims to be.

Next, the server sends a CertificateRequest to the client, asking to see its certificate. The STB transmits its STB device-specific certificate in response. The server authenticates this with its copy of the STB root certificate, and then knows that the client is who it claims to be.

This authentication process is completely automatic between browser and server, and does not require any manual effort beyond the initial configuration of the server and STB boot image.

Configuration

In order for the STB to authenticate the server, a copy of the server root certificate needs to be available in the STB boot image. You do this by adding the following to the boot image configuration file:

# install server root certificate for mutual authentication
kreatv-option-https-certificate-override::default.ca-bundle=/path/to/server-rootCA.pem

In addition, the server needs a copy of the STB's root certificate. This is located at <sdk_root>/dist/config/certs/arris_device_root.pem. Please see your web server's documentation for adding the root certificate and enabling mutual authentication.

Using a custom STB certificate and key

The STB contains an ARRIS device-specific certificate and an STB private key, installed during the factory production, but it is possible to add and use custom ones, too. Please consult the Ekioh browser documentation if you need any more details about this option and the requirements of the certificates and private keys. You would add the following to the boot image configuration file:

# optionally install a custom STB device-specific certificate and private key
kreatv-app-webkit-portal::vendor_config=ssl.client.certs.path:/etc/tls/webkit/
kreatv-option-https-certificate-override::webkit.client=/path/to/custom-STB.pem

Additional signing and verifying of application data

Even though the server and STB have now authenticated each other in the above case, it is sometimes required to pass important data between the STB and the server in a tamper-proof way. To achieve this, KreaTV offers a signing and verifying service.

Signing data

To sign data from within an application on the STB, you can use ToiApplicationService.signData() which makes use of the STB's private key. Note that the web server must be configured with a copy of the STB device-specific certificate to be able to validate the data.

It is also possible to provide a custom key to use when signing, please see the documentation for kreatv-option-authentication for more details.

Verifying data

To verify signed data sent by the server, the STB application can use ToiApplicationService.verifySignature(). The server's public keys must be provided at boot image build time by using the kreatv-option-authentication IIP.

Signatures

Every now and then it is useful or even required to add some kind of assurance that transmitted data hasn’t been tampered with in transit, and that it was sent from a specific entity, e.g. a specific web server or a specific STB. This is achieved by creating a signature for the data that we want to secure. Signatures are based on public key cryptography and KreaTV supports RSA. A signature is created by creating a one-way hash for the data to be signed and then encrypt this hash value using the private key of the RSA key pair.

On the set-top box

Signing data is straightforward for the portal developer. It is performed by calling ToiApplicationService.signData() and supplying the following input arguments:

• The data to sign
• The name of the key to use for signing the data, as there may be several keys available.

The resulting signature is a base64 encoded string to simplify inclusion in HTTP requests as illustrated below:

var http = new XMLHttpRequest();
var url = "http://mysite.net";
http.open(“POST”,url+”auth?signature=”+toi.ToiApplicationService.signData(myKey, myData)+”&data=ABC123”);
http.send();

Verifying signatures is also straightforward. It is performed by calling ToiApplicationService.verifySignature() with the following input arguments:

• Which key to use
• The data that allegedly has been signed
• The signature for the data

It is up to you, the portal developer, to choose the correct key. There is no mechanism offered by KreaTV to do this.

On the web server

The inner workings of the signatures shouldn’t matter to the portal maker but it is of importance to a server/back end developer. KreaTV-constructed signatures follow the blue print given below. Note carefully that KreaTV also expects that the signatures it evaluates follow the same blue print:

1. Create a hash for the data that is going to be signed. The reason to use a hash is that it simplifies the final encryption stage. SHA-256 must be used as the hashing function.
2. Since the hash value is only 256 bits it must be padded to match the length of the RSA key used in the final encryption stage. Padding shall be done according to PKCS#1 v1.5 with the block type parameter set to 01 (see RFC2313 for details).
3. Encrypt the padded hash value with the appropriate RSA private key.

To verify a signature two items are needed, the RSA public key counterpart to the RSA private key used to encrypt the hash value, and the data for which the signature was created.

The steps for verifying a signature are as follows:

1. Decrypt the padded hash value and strip away the padding.
2. Calculate a hash value of the data using SHA-256.
3. If the decrypted and stripped hash value matches our own calculated hash value then the signature was correct.