Trustworthy Communications

March 2014

Each day we become more reliant on the Internet in both our personal and business lives, yet each day there are new stories of security failures. A key part of living and working on the Internet is the ability to be able to communicate securely; whether inter-personal communication, such as email or chat, or client / server communication to access a web site.

This blog looks at how and why secure communications fail, and what we can do about it.

Trust

To be able to communicate securely, in any form, you need a basis of trust, for example:

• Is the client application trustworthy (e.g., App or web browser): will it leak my data elsewhere; can an attacker gain access to private information?

• Is the server (e.g., web site) trustworthy: will it take care of my data; who will it share my data with (legitimately as part of the terms of reference I signed up to); how resilient is to a determined attacker?

• Is the communication secure: can my data be intercepted between client and server; have I connected to the right server?

• How do I demonstrate to the server, I am the genuine user, and not a fraudster?

The issue behind many of the never-ending stream of security failures, is that somewhere along the line trust has failed.     In this article, I am going to focus on a subset of these failures, as related to SSL, or more generally public key cryptography.

Public Key Cryptography

Before continuing, I need to briefly explain some crypto terminology around public key cryptography.

Public key cryptography is about a set of techniques that together combine in a particular system to enable secure communication; different systems use different combination of these techniques.   The most commonly referred to system is a group of public-key cryptography standards (PKCS) devised and published by RSA.  Example techniques include encryption techniques (symmetric and asymmetric), certificate formats, key exchange algorithms and revocation approaches.

Example of secure public key handshake, using the ever-present Alice and Bob.

PKI is a set of Public Key Cryptography tools, combined with policies and procedures used to create a trust hierarchy – an infrastructure.  A core part of PKI is the certificate authority, a point of trust that issues cryptographic tokens to servers and users to enable them to assert their authenticity.  To do this, the certificate authority needs to provide a trust anchor – the root certificate.

A Public Key Cryptography and Public Key Infrastructure (PKI) are not the same thing – public key systems can exist and work independently of a PKI – a vital point often overlooked.

A common technique used in security client/server communications is the Secure Sockets Layer (SSL, more correctly know as TLS, but the old name SSL is more commonly used).  SSL uses public key cryptography techniques.

Trust Failures

So with great techniques such as these, why are we seeing so many security failures related to public key cryptography?  The issue is that we have seen too many failures in trust:

• The security procedures of certificate authorities (PKI) have been shown to be lax, for example leading to the spectacular failure of Diginotar – a previously well respected and trusted certification authority.

• On the client side public key systems often need the user to keep a key secure; these are too complex to remember so have to be stored somewhere.   How securely are they stored, and how secure was the mechanism that generated the key and stored the key there in the first place?   Smart cards are often cited as the answer to this, but how secure are they...
  

  Protocol flaw which allows criminals to use a genuine card to make a payment without knowing the card's PIN, and t…http://t.co/l7ap1W2y3i
  — Ed Alcantara (@CyberBlackOps) February 21, 2014

• Fake SSL certificates have been circulating in Internet and widely reported…
  

  Fake SSL certificates deployed across the internet http://t.co/UfZf48reUW
  — Andrea Servida (@ServidaAndrea) February 17, 2014

  The issue is not actually the fake SSL certificate, but the verification of the cryptography trust chain has been weak. The whole point about PKI is it exists to enable checks to be made as to the validity of a set of credentials. You can trace everything back to the trust anchor (root certificate) and check these are not known to have been compromised (revocation). If these checks were done, the fake SSL certificates would be spotted (the whole point of PKI).   This is a common failing in Apps, incredibly even in banking apps.

• The implementation of SSL needs to be robust, something Apple, among many others had to fix recently…
  

  Apple Encryption Flaw: "It's as bad as you could imagine" http://t.co/ThtjDZsKbV #HackSurfer #infoSec #cyberSecurity

  — Porter Hicks (@PorterHick) February 22, 2014

Solutions

There are multiple approaches to solving these kinds of issues, I am going to explore two of these a little further: certificate trust chains and trustworthy software.

Certificate Trust Chains.

With a PKI model you are effectively delegating trust to a set of third parties.  The certification authority (and Diginotar has cast doubt on the level of trust you can place in a CA) and your client application.   The client application needs to establish if it is prepared to trust the certificates it is presented with.  A web browser does this by delegating trust to a set of certificates stored in the root certificate store – but how did these get there, and who said they are trustworthy (I counted 46 root certificates in by browser at the time of writing) – yet another 3rd party to trust. This is why we are starting to see some Apps use a technique call certificate pinning.  In short, the App has a hard coded certificate related to the server it is prepared to trust.  At first sight somewhat inflexible if the certificate needs to be re-issued or revoked – but on the other hand this is in control of the App developer by simply issuing an App update.  This is a core example of using public key cryptography, but working around the issues with PKI. Aside:  certificate pinning was cited as one of the issues with WhatsApp - somewhat unfair to single out WhatsApp, but it's topical…

Among the most serious problems with WhatsApp's implementation of secure sockets layer (SSL) encryption is its suppo…http://t.co/OdCYWHQV30

— Ed Alcantara (@CyberBlackOps) February 21, 2014

At NEXOR, we take this very seriously, hence our research and development into secure booting of our appliances – making sure our appliances have a good, trustable reference point before the business application starts.

Trustworthy software

As explored, one of the common failures is poor software, Apps that simply don't do the basics, cryptographic systems that overlook a key weakness… Software has to be designed secure from the start.  This requires a set of robust processes, incorporated with threat analysis, subjects already covered in this blog series.  Sadly today, such approaches are not wide spread, something the Trustworthy Software Initiative (TSI) has been set up to address.  TSI aims to collect, organise and share the wealth of knowledge, experience and capabilities that already exist in the UK public and private sectors and in academia about trustworthy software to give people a joined-up, curated view of the information that is available

Security is hard.  Only by taking a methodical approach, designing security in from the start, analysing what you can trust and what you need to validate, can you start to eliminate some of the common points of attack.

In conclusion, this blog has explored how and why secure communications fail – essentially trust failures.  We have then explored what can be done about it – being very careful about what you trust and the basis of that trust.  A key component of stopping the daily news stories about security failures has to be the insistence of the use of trustworthy software.

Can we help you with your trustworthy software development?

Be the first to know about developments in secure information exchange

We value your privacy Find out more >