IPsec stands for Internet Protocol Security. It is a standards framework for securing IP (Internet Protocol) communications. The key differentiator for IPsec is that it provides security at the network or packet processing layer of the protocol stack. Typically, security is provided at the application layer. IPsec, on the other hand, provides security services at the IP layer that other protocols and applications can use.

The two key components of IPsec are the Authentication Header (AH) and the Encapsulating Security Payload (ESP). As its name implies, AH provides authentication services. In other words, the recipient of a message can verify that the sender of the message is legitimate. AH also permits the recipient to verify that the data in a message has not been altered or tampered with. Replay attacks where a message is resent by an illegitimate user are also countered by AH.While AH supports data integrity, ESP supports data privacy by encrypting the contents of an IP packet. Thus, using IPsec, data can be authenticated and encrypted. There are also support components for fundamental cryptography operations such as hashing and encryption algorithms and key management.

IPsec is ideally suited for Virtual Private Networks (VPNs). A VPN is a private network that uses the Internet or other public network to connect remote sites and users together. A secure VPN usually uses IPsec to 'tunnel' between the two endpoints (sender and receiver). As most IPsec solutions require hardware and/or software installation on machines accessing the VPN this effectively acts as an extra layer of security as anyone attempting to access the network illegitimately would require additional hardware or software installation.

Not all VPNs use IPSec. Some use Secure Sockets Layer (SSL).  The primary reason for this is financial as IPsec does require specialised software or hardware. SSL VPNs also have the advantage of being more focussed as they can be used to create a tunnel for a specific application rather than the entire corporate network. However, in general they are only appropriate for web-based applications.

There are number of open source IPsec implementation including OpenSwan for LINUX (See http://www.openswan.org/). Similarly, an SSL-based VPN is available from Open VPN (See http://openvpn.net/).

IPsec and SSL are both enablers of VPNs. Given the prevalence of networks emerging for smart grids and eocsystems and the confidential nature of much of this data both could play a key role in providing VPNs for CleanTech and Smart Infrastructure solutions.

Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are cryptographic protocols that secure data in transit over communications networks such as the Internet. SSL was originally developed by Netscape (http://aol.netscape.com). It uses public key cryptography (or in other words two keys) to encrypt data - a public key that is known by everyone and a private key that is known only by the message recipient. Web addresses (or URLs - Uniform Resource Locators) that require an SSL connection are prefixed with https:// rather than http://. SSL creates a secure connection between a client and server over which any volume of data can be sent securely.

If an organisation wishes to secure communications to their web server it must create a public and private key - known as a certificate. The organisation must then go to a trusted third party such as Thawte (http://www.thawte.com) or Verisign (http://www.verisign.com). In the case of Thawte, the organisation must prove its identity and the right to use their domain. Once verification is complete, the organisation is issued with a new public key representing certification. The certification information is encrypted using the third party's private key.

When a client wishes to communicate with the organisation's web server it will make a connection with its computer to a special port on the organisation's server that is set up for SSL communications only. The organisation will then send back its public key. When the client receives the public key it must decide if it's acceptable i.e. check that it isn't expired, that it's for the correct domain etc. The client will have the public key for many third party certification authorities on its computer and can decrypt the validation information and prove that the public key is certified. If the client trusts the third party then the client can trust that it is really communicating with the organisation.

Transport Layer Security (TLS) is commonly referred to as the successor to SSL. The aim of the protocol is the same - when two parties communicate, TLS ensures that a third party can't eavesdrop on the communication. The protocol is composed of two layers - the TLS Record Protocol and the TLS Handshake Protocol. The former provides connection security using an encryption protocol such as the Data Encryption Standard (DES) but can also be used without encryption. The TLS Handshake Protocol allows the client and server to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged. Despite being based on SSL, TLS and SSL are not interoperable. The main advantage of TLS lies in how it has been developed. Being based on open community standards, it is more extensible than SSL. Furthermore, TLS provides support for unsecure and secure connections on the one port whereas SSL does not.

There are a number of open source toolkits that implement SSL and TLS. The OpenSSL project (http://www.openssl.org) is a collaborative project to implement both SSL and TLS and also provides a cryptographic library. OpenSSL is free to download and is written in the C programming language. A good 'how-to' tutorial on SSL is provided by IBM (http://www.ibm.com/developerworks/linux/library/l-openssl.html) which demonstrates how to create an unsecured connection and a secure SSL connection. OpenSSL has extensions to support a number of cryptographic algorithms including  Elliptic Curve Cryptogaphy (ECC) and Identity Based Encryption (IBE) as well as supporting common ciphers such as DES and Blowfish, RSA (standing for its authors Rivest, Shamir and Adleman) public key cryptography and X.509 certificates. 

Another open source SSL/TLS toolkit is PolarSSL (http://www.polarssl.org). PolarSSL is also written in the C programming language and its authors state that it has been developed with embedded systems in mind. It is a lightweight system and supports common symmetric encryption algorithms, hash algorithms and certificates. ECC support is also planned. PolarSSL can be used for free for personal/educational use and for commercial applications that conform to certain criteria.

The big disadvantage of both SSL and TLS is that communication is slower than similar communication without these protocols. In the case of SSL, implementation takes place on top of the TCP/IP layers so implementation programmers need to have detailed knowledge of the operating system (OS) and system calls. However, if an organisation wishes to secure their communication use of one of these protocols or an alternative (such as IPSec which we will cover in a subsequent blog) is mandatory.