3Investigations about SSL |
|
3 INVESTIGATIONS ABOUT SSL |
3.1 SSL/TLS |
|
Secure Sockets Layer (SSL) was originally an initiative of Netscape Communications. The Internet Engineering Task Force (IETF) adopted SSL for its Transport Layer Security (TLS) protocol. The WAP Forum adapted TLS to create a wireless equivalent, Wireless Transport Layer Security (WTLS).
The differences between (several versions of) SSL, TLS and WTLS will be discussed later; conceptually, they provide the same security service: a secure channel between two entities, a client and a server.
SSL/TLS/WTLS provides a secure communication channel between a client and a server. This means that the data that is transmitted between both ends is kept secret (confidentiality) and that tampering will be detected (data integrity); the server is (almost) always authenticated; the client can be required to authenticate too. Today’s applications however mostly rely on another client authentication mechanism on top of the secure channel (e.g, password-based). Thus, SSL/TLS provides entity authentication, data authentication, and data confidentiality.
As SSL/TLS/WTLS only provides a secure channel, it does not provide non-repudiation: at the receiving side, the transmitted data leaves the secure channel, and the cryptographic protection is removed; there is no digital signature on user data. Non-repudiation (a well as any other security property needed in an electronic voting system) should typically be provided by additional means on top of the secure channel.
Within the protocol stack, SSL/TLS is situated underneath the application layer. An advantage of this is that it can in principle be used to secure the communication of any application, and not only between a web browser and server (e.g., IMAP, FTP, Telnet).
In short, SSL/TLS works as follows:
· public-key cryptography is used to authenticate the participating entities, and to establish cryptographic keys;
· symmetric key cryptography is used for encrypting the communication and adding Message Authentication Codes (MACs), to provide data confidentiality and data authentication respectively.
3.1.3.1 Handshake and data transfer
A connection between the client and the vote server is divided in two phases, the handshake and the actual data transfer.
The purpose of the handshake is threefold:
· client and vote server need to agree on a set of cryptographic algorithms that will be used to protect the data, to authenticate each other, and to agree on cryptographic keys;
· secondly, they need to establish a set of cryptographic keys with which data will be protected;
· lastly, the vote server authenticates to the client and, optionally, the client authenticates to the vote server.
Once the handshake has been completed, data transfer can take place.
· Data is broken up in fragments, and transmitted as a series of protected records.
· To provide data integrity, a Message Authentication Code (MAC) is computed over a data fragment;
· fragment and MAC are then encrypted.
3.1.4 SSLv2/SSLv3/TLS/WTLS: differences
3.1.4.1 SSLv2 vs. SSLv3/TLS
The first public version of SSL, version 2, suffered from a number of security flaws, which have been fixed in SSLv3. As browsers nowadays still support SSLv2, and as it is still in use in some systems, we briefly sum up its security problems:
· the same cryptographic keys are used for message authentication and for encryption, which means that in export mode also the MACs are unnecessarily weakened (due to U.S. export restrictions, the symmetric key length that could be used in Netscape and Internet Explorer was limited to 40 bits. If the restricted data encryption key is also used for message authentication, the security of the MACs is also crippled, although this was not required by the U.S. export restrictions);
· SSLv2 has a weak MAC construction and relies solely on the MD5 hash function;
· SSLv2 does not have any protection for the handshake, so that a person-in-the-middle attack cannot be detected;
· finally, a truncation attack is possible, as SSLv2 simply uses the TCP connection close to indicate the end of data, so that the attacker can simply forge the TCP FINs and the recipient cannot tell that it is not a legitimate end of data (SSLv3 fixes this problem by having an explicit closure alert).
Note that before SSLv3 was proposed, these security problems were also solved by Microsoft in their Private Communications Technology protocol. PCT is very similar to SSL/TLS and is still supported in Microsoft's web browser and server, but SSL/TLS has become the standard and PCT is thus not widely deployed at all.
3.1.4.2 SSLv3 vs. TLS
The IETF TLS working group adopted the SSLv3 protocol. Some minor modifications were made to increase security:
· the way cryptographic keys are expanded from the initially exchanged secret was improved;
· the MAC construction was slightly modified into an HMAC;
· and, implementations were required to include support for the Diffie-Hellman key agreement, the Digital Signature Standard, and Triple-DES encryption.
3.1.4.3 TLS vs. WTLS
The WAP Forum has adapted TLS to make it suitable for a wireless environment with small devices, which have limitations on bandwidth, memory and processing.
· WTLS therefore includes the usage of elliptic curve cryptography by default;
· WTLS does also work on top of a datagram instead of a connection based communication layer (compare to UDP vs. TCP on the Internet);
· finally, WTLS defines its own certificate format optimized for size, but supports the ordinary X.509v3 certificate too.
3.1.5 Cryptographic algorithms
The TLS specification (IETF RFC 2246) supports several cryptographic algorithms. During the handshake phase of the protocol, client and server can negotiate the particular algorithms that will be used in the session. This is done by choosing a particular “ciphersuite”. A ciphersuite is actually a set of cryptographic algorithms.
3.1.5.1 Ciphersuites
The following ciphersuites are specified in the TLS specification:
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
Each ciphersuite is thus a set of cryptographic algorithms, consisting of an authentication and key establishment algorithm, a symmetric encryption algorithm, and a cryptographic hash function (the latter is used within the HMAC construction).
3.1.5.2 Authentication and key establishment algorithms
DHE_DSS: Ephemeral DH with DSS signatures.
DHE_DSS_EXPORT: Ephemeral DH with DSS signatures (DH up to 512 bits).
DHE_RSA: Ephemeral DH with RSA signatures.
DHE_RSA_EXPORT: Ephemeral DH with RSA signatures (DH up to 512 bits).
DH_anon: Anonymous DH, no signatures.
DH_anon_EXPORT: Anonymous DH, no signatures (DH up to 512 bits).
DH_DSS: DH with DSS-based certificates.
DH_DSS_EXPORT: DH with DSS-based certificates (DH up to 512 bits).
DH_RSA: DH with RSA-based certificates.
DH_RSA_EXPORT: DH with RSA-based certificates (DH up to 512 bits).
NULL: No key exchange.
RSA: RSA key exchange.
RSA_EXPORT: RSA key exchange (RSA up to 512 bits).
‘Ephemeral’ means that Diffie-Hellman parameters are generated on the fly. They are then signed by the long term DSS or RSA key.
RSA key exchange is actually (pre-master-) key forwarding from client to server. Server authentication is implicit (server can decrypt the pre-master-secret). Client authentication is explicit by signing the previously exchanged handshake messages.
3.1.5.3 Symmetric encryption algorithms
NULL: no encryption.
IDEA_CBC: block cipher IDEA in CBC mode.
RC2_CBC_40:block cipher RC2 with 40bit key.
RC4_40: stream cipher RC4 with 40bit key.
RC4_128: stream cipher RC4.
DES40_CBC: block cipher DES in CBC mode with 40bit key.
DES_CBC: block cipher DES in CBC mode with 40bit key.
3DES_EDE_CBC: block cipher 3DES in (outer) CBC mode, with 168bit key.
3.1.5.4 Cryptographic hash functions
NULL: no data authentication.
MD5: HMAC using MD5.
SHA: HMAC using SHA-1.
3.1.6 Current status of IETF-TLS Working Group
The IETF-TLS working group is currently working on several enhancements of the TLS protocol. This is reflected through several additional Internet Drafts and RFCs besides the main RFC 2246.
At the time of writing of this section (October 2001), the following extra documents were published on the IETF web site:
· Extra cipher suites:
o ECC Cipher Suites For TLS
o 56-bit Export Cipher Suites For TLS
o Extensions to TLS for OpenPGP keys
o Addition of MISTY1 to TLS
o AES Ciphersuites for TLS
o Addition of the Camellia Encryption Algorithm to TLS
o NTRU Cipher Suites for TLS
o Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (RFC 2712)
· Extra functionality:
o TLS Delegation Protocol
o Using SRP for TLS Authentication
o TLS Extensions
o TLS Pathsec Protocol
· Use of TLS in HTTP:
o Upgrading to TLS Within HTTP/1.1 (RFC 2817)
o HTTP Over TLS (RFC 2818) (15170 bytes)
The Internet Draft on “TLS Extensions” is particularly interesting as it includes wireless extensions to TLS. These wireless extensions are very similar to the WAP WTLS specification.
3.2 Export restriction issues |
|
There used to be severe U.S. export restrictions for cryptographic software. As a consequence, popular web browsers (i.e., Microsoft Internet Explorer and Netscape Communicator) could not contain (activated) strong cryptography when exported outside the U.S. In particular, the length of a symmetric cryptographic key used to be limited to 40 bits; asymmetric keys were limited to 512 bits.
Several solutions were developed that ‘circumvented’ these export restrictions. Although cryptographic software can currently be exported from the U.S. to most other countries without any restrictions, these solutions remain noteworthy.
Note that besides the U.S. export restrictions each country has laws regarding the use of cryptography (whether or not imported from the U.S.) [12].
3.2.2.1 Fortify
Exported browsers did contain strong cryptography. However, it was de-activated. For Netscape, a small program was made available on the Internet to activate this strong crypto (http://www.fortify.net/).
3.2.2.2 Server Gated Cryptography
During the relaxation of the export restrictions, financial institutions were allowed to enable the strong cryptography that was already present in browsers. This was technically done through the use of special server certificates with particular extensions. This technology is referred to as Microsoft’s “Server Gated Cryptography” (SGC), Netscape's International “Step-Up” encryption and Verisign's “Global Server ID”.
3.2.2.3 Own implementation of SSL/TLS
In many applications nowadays (e.g., electronic banking), a proprietary implementation of SSL/TLS external to the browser is still used.
This can be included in a stand-alone application that provides the necessary security as well as the other functionality of the application. Sometimes a stand-alone application is only used as a proxy running on the local machine of the client, that sits in between the browser and the web server, and adds strong security for the communication between the client and the server (while the communication between the browser and the proxy remains weak).
In many cases, program code including strong security and other functionality is just downloaded as an applet, and runs within the browser. This applet can again have complete functionality, or behave as a proxy in between the browser and the server.
3.3 Trust issues |
|
SSL/TLS depends on a Public Key Infrastructure. Participating entities should have a public/private key pair and a certificate. Root certificates should be securely distributed in advance. Private keys should be properly protected. These two elements, i.e., distribution of root certificates in browsers and the protection of private keys, are actually one of the weak and exploited points with respect to WWW security.
3.3.1 Distribution of root certificates
The authentication of the web server relies on a Public Key Infrastructure. The authentic distribution of ‘root’ certificates is here very important. They are used to verify entity's certificates, so without them, it is impossible to authenticate entities. Worse, if the root certificates on a client's machine are replaced by fake ones, it is possible for an attacker to impersonate the server, without the client noticing it.
Root certificates are usually included in the installation of today's web browsers. Note that by default all root certificates are trusted, and that for a proper secure connection (i.e., without a warning to the user), a web server certificate has to be issued by any of the trusted roots (which is not always the one the user expects!).
For stand-alone applications, a root certificate is usually hard-coded in the software, or put in a configuration file. In all cases, they are mostly only protected by the operating system.
To be able to trust the correct execution and interface, the user should have a genuine copy of the browser or the stand-alone application. In case a Java applet is used, this should be digitally signed (see Microsoft's ‘Authenticode’ or Netscape's ‘Object Signing’), so the user can verify it before actually executing it (again, the correct root certificate is here needed!).
This brings us to the security of the client's platform the browser or application is running on. Unfortunately, typical end users' platforms have shown to be very vulnerable to viruses, Trojan horses, worms, etc. These malicious programs cannot only tamper with the installed root certificates and steal the private keys stored in software. They can also spoof the interfaces, mislead the users, and intercept communication before it is ‘securely’ sent to the vote server (e.g., if the application includes a proxy on the client's machine that provides the end-point of a secure channel to the vote server, a malicious program could sniff the communication between the browser and that proxy). Even using smart cards is not necessarily a countermeasure against this problem, e.g., if a PIN code to unlock the card, has to be typed in via the ordinary keyboard.
3.4 Support of SSL/TLS/WTLS on different platforms |
|
SSL/TLS/WTLS is supported to more or less extent on the different platforms targeted by the CyberVote project.
Today’s popular browsers implement the SSL/TLS protocol by default. Netscape Communicator (4.7) only supports SSL and does not support TLS, while Netscape 6, Microsoft Internet Explorer and Opera do support both SSL and TLS. Note that in addition Microsoft also supports their own PCT 1.0 protocol.
The previously mentioned browsers all support the RC2, RC4, DES, 3DES symmetric algorithms, and MD5 and SHA-1 cryptographic hash functions. They only provide full support for RSA, while DH key establishment is not foreseen.
Note that Netscape and Opera allow the user to select preferred ciphers, while Microsoft Internet Explorer does not provide a user interface through which ciphers are configurable.
3.4.2 Mobile phone (Nokia 9210)
The Nokia 9210 (and many other mobile phones) supports WAP, and thus WTLS. The CyberVote demo however does not rely on WAP, but uses a GSM data call to an ISP as the underlying communication channel and sets up a PPP connection over which standard TCP/IP applications can communicate.
Support for SSL/TLS can be built into a dedicated voting application, or one can rely on the SSL/TLS functionality of a browser. Opera provides a browser for the Symbian OS, the operating system of (among others) the Nokia 9210. This browser offers the same SSL/TLS features as the regular Opera browser for PC systems.
The Pocket PC includes a pocket version of Microsoft Internet Explorer. This version offers less functionality than the regular version. (Minimal) SSL/TLS support is however provided.
3.5 Appropriateness of SSL/TLS to the CyberVote system |
|
The SSL/TLS protocol provides a secure channel between a client and server entity. Data exchanged between client and server is authenticated, encrypted, and integrity-protected. However, no other security services are provided by SSL/TLS. Moreover, all cryptographic protection is only applied during transit of the data, and is removed once it is received at the other end of the secure channel.
SSL/TLS might therefore be used to implement a very basic voting system. As already mentioned in D6, it is much more appropriate to rely on SSL/TLS as an additional security measure besides the CyberVote voting protocols, and whenever a secure communications channel is required.
SSL/TLS is particularly suited to provide authentication of the different web servers that are involved in the voting system, e.g., servers that provide crucial guidelines to the voters, as well as servers that provide the software needed to participate in the voting process. As such, SSL/TLS can prevent that malicious parties try to masquerade as genuine voting entities.
